Форум MySQL

Во многих статья по оптимизации mysql везде пишут что что для более быстрой работы следует использовать постоянное mysql_pconnect соединения.
Вот поставил на сайт, вроде особой разницы незаметил, но остались непонятные моменты.
Во всей логике при постоянном соединение должен быть 1 процесс, который бы выполнял последовательно все команды но в процессах висит постоянно 10-12 процессов с одним и тем же пользователем и постоянным id процессов(которые редко но иногда все же изменяються).

Разве так должно быть? Соединение же 1 должно быть? А выходит что 10-12 разных.

Завершить    2425952    user1    localhost    db1    Sleep    12    ---    --- Завершить    2426019    user1    localhost    db1    Sleep    1    ---    --- Завершить    2426029    user1    localhost    db1    Sleep    2    ---    --- Завершить    2426035    user1    localhost    db1    Sleep    3    ---    --- Завершить    2426037    user1    localhost    db1    Sleep    1    ---    --- Завершить    2426038    user1    localhost    db1    Sleep    7    ---    --- Завершить    2426042    user1    localhost    db1    Sleep    11    ---    --- Завершить    2426043    user1    localhost    db1    Sleep    1    ---    --- Завершить    2426045    user1    localhost    db1    Query    1    Updating    UPDATE PASSWORD SET n = n +1 WHERE ip = '95.58.119.33' LIMIT 1  Завершить    2426073    user1    localhost    db1    Sleep    2    ---    --- Завершить    2426118    user1    localhost    db1    Query    1    Sending data    SELECT count( * )  FROM znam WHERE razdel LIKE '%%/1930/%%' Завершить    2426119    user1    localhost    db1    Sleep    4    ---    --- Завершить    2426120    user1    localhost    db1    Sleep    3    ---    ---

>Во многих статья по оптимизации mysql везде пишут что что для более быстрой работы следует использовать постоянное mysql_pconnect соединения.

Сколько из них говорит именно о php?

5.2.12 Другие советы по оптимизации

Советы для повышения скорости систем:
Используйте постоянные соединения с базой данных, чтобы избежать издержек на подключения. Если невозможно использовать постоянные соединения и осуществляется большое количество новых подключений к базе данных, то можно изменить значение переменной thread_cache_size. See section 5.5.2
взято с mysql.ru

Тут конечно не говориться прямо о php или не php, но как то совсем это бредово писать такое только относящемся к 1 не самымому популярному виду подключений.

>Тут конечно не говориться прямо о php или не php, но как то совсем это бредово писать такое только относящемся к

Ну, это уже Ваши впечатления.
Надо же понимать природу процессов в http-сервере.

Тоесть вы точно наверняка можете сказать что mysql_connect при подключении через php будет работать быстрея чем mysql_pconnect:?

Сервер будет работать быстрее точно. Если постонные соединения не выжрут всю оперативную память - разницы в скорости вы не заметите, если выжрут, то замедлится в том числе работа и вашего сайта. Проверенно многократно экспериментальным путем. Постоянные соединения в связке MySQL+PHP лучше не использовать.

если я не ошибаюсь, PHP начинает работу с "чистого листа". т.е. запуская скрипт, php не помнит ни о каких прошлых соединений, открытых файлах.. выполнив все, он все стирает.. сделано чтоб не допускать утечки памяти..

php - это одно, а mysql - другое

если php не помнит, он по новой пытается создать соединение. или я ошибаюсь? и кол-во соединений не превысит кол-во процессов апача?

Не превысит, если скрипт не пытается открыть больше двух соединений (с разными параметрами), но обычно хватает и нескольких десятков подвисших и потребляющих ресурсов процессов, чтобы существенно замедлить работу сервера (кроме того, количество соединений с MySQL также ограничено).

если я не ошибаюсь, апач создает потомки и потомки уже выполняют работу. допустим, конфиг не более 20 потомков. значит будет не более 20 соединений?

а если стоит, допустим, php-fpm/ там кол-во процессов всегда постоянно. и они всегда существуют. так же от кол-во процессов?

и какая опасность, что соединение открыл 1 потомок, а потом начал работать другой потомок?

>и какая опасность, что соединение открыл 1 потомок, а потом начал работать другой потомок?
Не очень понятно, а в чем опасность? Ну да в UNIX процессы создаются fork-ом, однако, это не означает, что MySQL-соединение из процесса в процесс кочует. Или имеется в виду что-то другое?

>это не означает, что MySQL-соединение из процесса в процесс кочует.

вот об этом я и говорю, что новый процесс новое соединение, после процесс умирает, а соединение? По этой причине забивается маск. кол-во соединений с mysql?

при php-fpm нет новых процессов... там сколько прописал в конфигах столько и будет процессов с запуска. столько же и будет соединений с БД?
т.е. можно не переживать за них?
(при условии, что скрипты используют только 1 соединение)

допустим, у меня 10 процессов php-cgi, я могу спокойно писать в конфигах mysql о 10 одноврем. соединений? или все же php каждый раз создает новое соединение? не "помня" о прошлых соединениях?

>вот об этом я и говорю, что новый процесс новое соединение, после процесс умирает, а
>соединение? По этой причине забивается маск. кол-во соединений с mysql?
Процесс не умрет, пока к нему имеются обращения, а уже тем более установленные соединения с mysql. Будет ждать, процессы, насколько я помню, должны обслужить определенное количество запросов, после чего они уничтожаются.

>при php-fpm нет новых процессов... там сколько прописал в конфигах столько и будет
>процессов с запуска. столько же и будет соединений с БД?
Если у вас один сервер и один сайт - можно не переживать, если несколько, лучше отказаться от постоянных соединений.

>допустим, у меня 10 процессов php-cgi, я могу спокойно писать в конфигах mysql о 10
>одноврем. соединений? или все же php каждый раз создает новое соединение? не "помня" о
>прошлых соединениях?
В случае CGI (не модуля), вероятно да, при условии, что у вас на сервере больше нет никаких других проектов (и MySQL не нужна для работы почты, DNS, FTP или чего-то ещё) - иначе они захватял все 10 соединений, а другие будут ждать.

спасибо... =) попробую использовать..