Есть сайт с приличной нагрузкой часть пользователей на котором отваливаются по 504 ошибке. nginx отдает статику, apache разруливает php. mysql крутится на другой машинке. Узкое место больше склоняюсь в mysql. Немного о той машинке: core duo, 8 gb ОЗУ Загрузки по процессору нет, la меньше 1. iowait в среднем 10% - вся база в память не лезет. mtop показывает кучу sleep'ов и есть запросы которые обрабатываются по/более 50 секунд судьба их дальше не известна. Примерная картина в mtop:
"mysql.allow_persistent = On" Off как то боязно пробовать. Смущает "Cache Hit: 99.93%" На графике оно вроде так же присутствует, но пропорции не 99%.
Мысли - что дело не в железе/нагрузке, а некорректной работе/недонастроенном bitrix'е Так как машинка досталась недавно в настройках php_interface/dbconn.php там: define("CACHED_b_iblock", false); define("DBPersistent", true); @ini_set("memory_limit", "96M"); Подскажите, куда копнуть, что подстроить. зы: машинка на Linux
Причина: спящие процессы появляются потому, что при коннекте к базе данных используется mysql_pconnect "define("DBPersistent", true);", можно, конечно, отключить, но тогда нагрузка на сервак будет при постоянных коннектах к MySQL, отсюда возникает необходимость подчищать лишние коннекты(которые,между прочим, держат ресурсы сервера), почему до этого не додумались разработчики продукта - сие тайна . Решение: добавить в функции API битрикса Connect() Disconnect() следующий код(куда думаю сам разберешься):
Код
$result=mysql_query("SHOW PROCESSLIST");
while ($row=mysql_fetch_array($result))
{
$process_id=$row["Id"];
if ($process_id <> $this->db_Conn) //это чтобы не убить текущий коннект
{
if (($row["Time"] > 20 ) && ($row["Command"]=="Sleep") )
{
//print $row[”Id”];
$sql="KILL ".$process_id." ";
mysql_query($sql);
}
}
}
Время существования спящих процессов можешь выбрать сам, у меня стоит 20 секунд $row["Time"] > 20; Итог: нагрузка на сервер значительно уменьшилась, и пользователей перестало выбивать.
читай выше, отредактировал сообщение(добавил пояснение);
Цитата
Причина: спящие процессы появляются потому, что при коннекте к базе данных используется mysql_pconnect "define("DBPersistent", true);", можно, конечно, отключить, но тогда нагрузка на сервак будет при постоянных коннектах к MySQL, отсюда возникает необходимость подчищать лишние коннекты(которые,между прочим, держат ресурсы сервера), почему до этого не додумались разработчики продукта - сие тайна .
Интересно а как вы понимаете смысл работы mysqlp_connect? Он и используется для того чтобы при повторном соединение не открывать коннект, соответственно и процессы должны ждать. Дело не в продукте а в настройке сервера.
Интересно а как вы понимаете смысл работы mysqlp_connect? Он и используется для того чтобы при повторном соединение не открывать коннект, соответственно и процессы должны ждать
В том то и дело, для следующего коннекта оставляем текущий коннект, и все коннекты время "сна" которых меньше определенного времени ( у меня 20 секунд), потому что при следующих коннектах он не цепляется к спящим, а создает новые. И вот чтобы новые не создавались до предела( числа соединений к базе данных) вот для этого и создан этот код.
Может я что-то не понимаю но почему если все запросы должны отправляться по 1 соединению я вижу под 200 коннектов в "netstat -anp | grep 3306 | grep ESTABLISHED | wc -l" + если InnoDB осуществляется блокировка на уровне строки, а MyISAM на уровне таблицы нужно все же как то еще подумать о смене пола для таблиц Николай Рыжонин извиняюсь, 10-20 коннектов где поставить? Dmitry Valyanov define("DBPersistent", false); можно попробовать вечером поставить. Nik Semenov судя по коду он их будет прибивать, но будет ли переконнект? Или все будет просто отваливаться? Кстати вроде в mysql можно таймауты наподкрутить по этому поводу если я все правильно помню.
calculator пишет: + если InnoDB осуществляется блокировка на уровне строки, а MyISAM на уровне таблицы нужно все же как то еще подумать о смене пола для таблиц С улыбкой
Николай Рыжонинmax_connections - вот я о том и говорю, по идее по привышении то уж точно ошибки сыпаться будут или там как то реализовано повторные запросы отправлять?
В общем поставил: define("DBPersistent", false); max_connections=30 Нагрузка сейчас похоже не пиковая, но после тестов вида: ab -n 1000000 -c 50 http://xxx.ru/ и получаса наблюдений вроде ни одной 504 не видно. Хотя на базу похоже этот тест никак не влияет. После манипуляций почти до 0 упали "MySQL slow queries" и "MySQL threads". У кого нибуть есть идеи как потестить _полноценно_?
А что тут тестить у вас двух уровневая конфигурация и всего 5 процессов апача, соответственно больше 5 соединений они не откроют. Попробуйте при таком ограничение числа соединений снова включить DBPersistent и посмотрите что будет.
Николай Рыжонин Там апача стартовых 5 процессов, и на каждого сверх старта он рожает еще. Допустим сейчас там их 12. Пока DBPersistent сегодня трогать не буду - хочу посмотреть полный денек как работать будет, но а если все хорошо будет - попробую. Все таки за max_connections немного опасаюсь - когда привышение будет, наверно не будет переконнектов, будут просто отлупы. Denis Sharomov Я не клиент, скорее всего клиент человек, чей сервер мы администрируем.
Пара замечаний: 1. Зачем столько много апачей при двухуровневой конфигурации? Зависит конечно от конкретного случая но 3 - 5 постоянно запущенных, max servers = start servers должно хватить с лихвой. А освободившеюся память лучше тому же мускулю отдать.
2. Для мускуля достаточно выставить max_connections чуть большим количества процессов апача + небольшой запас, на случай подключения к базе других сервисов или через консоль. И ни каких ошибок не будет проверенно
Николай Рыжонин пишет: 1. Зачем столько много апачей при двухуровневой конфигурации? Зависит конечно от конкретного случая но 3 - 5 постоянно запущенных, max servers = start servers должно хватить с лихвой. А освободившеюся память лучше тому же мускулю отдать.
Николай Рыжонин Если не ошибаюсь, то в праймтайм там нагрузка на apache в среднем 7-8 запросов в секунду, так что max servers пока думаю оставить как есть. Про память я уже предлагал им, наверно все же в машинку с мускулем излишки лучьше поставить.