|
Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Есть сервер с mysql - если клиенты присоединятся к серверу БД через TCP/IP, то всё отлично и сервер держит и 300 и 500 одновременных конектов, но если соединение идёт через mysql.sock , то при 48 одновременных подключениях всё нормально, а если больше (64 - 100 и более), то некоторых клиентов отбрасывает с ошибкой
Can't connect to local MySQL server through socket '/tmp/mysql.sock' (11)
.
PHP который осуществляет подключения собран в виде модуля apache, таким образом все соединения обслуживаются и открываются от имени пользователя под которым запущен апач.
есть вероятно где-то в системе ограничение на максимальное количество процессов, которые могут открыть один и тот-же файл.
может кто знает как с этим бороться, подскажите пожалуста.
Система SUSE 11.1
В файле limits.conf ограничения на максимальное количество открытых файлов для апача и мускуля имеют следующий вид
apache hard nofile 65535
@apache hard nofile 65535
mysql hard nofile 65535
@mysql hard nofile 65535
Заранее спасибо за ответы.
Неактивен
Ошибку определили действительно правильно, но что конкретно ограничивает —
сказать сложно, SuSE под рукой нету. Смотреть стоит не только в ulimits, но и в
другие возможно установленные ограничения (SELinux, apparmor, etc.).
Неактивен
paulus написал:
Ошибку определили действительно правильно, но что конкретно ограничивает —
сказать сложно, SuSE под рукой нету. Смотреть стоит не только в ulimits, но и в
другие возможно установленные ограничения (SELinux, apparmor, etc.).
Ядро скомпилировано лично мною без поддержки SELinux и apparmor. Соответственно упомянутые выше пакеты в системе и не стоят.
С другой стороны апач может в 300 потоков одновременно отдавть один и тот-же графический файл и никаких проблем с доступом у него не возникает (правда он открывает его только на чтение,а не на чтение\запись)
Куда смотреть и куда копать - ума не приложу.
В РУнете о подобных проблемах почти ничего нет, а в буржуинском нете только упоминания об этой ошибке, но нет решений.
Причём упоминается как возникающяя редко в моменты пиковой загрузки сервера.
Неактивен
Для начала попробуйте определить — проблема со стороны сервера или со стороны апача.
Я бы выполнил что-нибудь типа
for n in `seq 500`; do mysql >/dev/null & done
Это откроет 500 сессий клиента на один сокет. Если посыпятся ошибки — надо копать в
сторону ограничений mysql / сокета. Если не посыпятся — надо копать в сторону ограничений
mod_php / apache.
Неактивен
После всевозможных перекомпиляций мускуля апача и пхп с различными ключами и различных версий выяснилось следующее - от ключей компиляции и версий программ это не зависит. Равно как и от тго префорк апач или worker.
500 клиентов по совету paulus запускал и всё работает.
решение проблемы нашлось неожиданно.
всё дело оказалось в переменной мускуля thread_cache_size, после того как она стала отличной от нуля (300) . всё заработало более менее, но эта ошибка всё равно возникает хотя и в тысячи раз реже. думаю что когда конект идёт по ТСР , то клиент в любом случае дожидается ответа от сервера из-за ТСРшных таймаутов., а вот через файл - не всегда успевает дождаться создания сервером потока, а очень редко не дожидается и подхвата закешированым потоком его соединения.
Знать бы как в клиенте можно регулировать таймауты при соединении через файл, то проблему можно решить окончательно, хотя и счас 300 потоков апача с инсертами и селектами держится почти нормально, лишь в начале прогона теста пока потоки ещё не созданы сервером и не загнаны в кеш пролетают эти ошибки..
вот так вот.
Неактивен
Очень странное поведение. Такое свойственно, скорее, FreeBSD, а не Linux (из-за
плохой реализации потоков). Установка thread_cache_size всего лишь предсоздает
потоки.... в любом случае, хорошо, что разобрались 
Неактивен
paulus написал:
Очень странное поведение. Такое свойственно, скорее, FreeBSD, а не Linux (из-за
плохой реализации потоков). Установка thread_cache_size всего лишь предсоздает
потоки.... в любом случае, хорошо, что разобрались
тем более странно, что разработчики mysql говорят что SUSE одна из платформ на которой должно всё работать как часики.
Неактивен
Проблема локализована окончательно.
Перекомпилено ядро с включением опции Memory Type Range Registers (MTRR) , отключением оптимизации по размеру, что повлекло компиляцию ядроа с оптимизацией О2, а также были отклбчены секюрити хукс в сокетах.
После этих манипуляций при использовании pconnect поблема исчезла вообще, а при использовании обычных подключений только 8 процентов отбрасывается с вышеозначенной ошибкой. И это при 600 000 соединений в час в обоих случаях.
При таком количестве соединений я думаю это неизбежно и полное устранение проблемы требует ограничения ресурсов (времени процессора) апача.
Неактивен
Страниц: 1
