Медленно открываются соединения между ядром и MySQL

zooxel · Сообщение **zooxel** » Вт янв 18, 2011 12:04

Ядро и мускуль разнесены на две разные машины.

MySQL-5.0.86
FreeBSD 7.0-PRERELEASE

ядро UTM 5.2.1-007
FreeBSD 6.2-STABLE

Сегодня утром установили новые 4-ех ядерные процессоры взамен 2-ух ядерных на сервере с мускулем и запустили ядро. Обнаружился непонятный эффект: соединения создавались с интервалом в 20-30 секунд каждое, т.е. 64 соединения создались за очень продолжительное время. Повторный рестарт ядра эффекта не дал.

Куда копать и где грабли?

Спасибо.

kamae1ka

попробуй обновить mysql

zooxel · Сообщение **zooxel** » Вт янв 18, 2011 17:32

Не сильно хочется тыкать пальцем в небо. Я понимаю, что можно попробовать и ось обновить до 8-й версии и мускуль тоже накатить последний, но где гарантия, что положение дел исправится и не появится новых пачка.

Также есть сомнения в том, что это поможет ибо, например, радиус-сервер, который также уюзает некоторые таблицы из утмовской базы цепляется без проблем и грузит все ядра обоих процов на полную катушку.

Нетап вежливо послал, т.к. нет купленной технической поддержки. Инет и форум порыл, но ничего путного не нашел.

ds · Сообщение ds » Вт янв 18, 2011 22:02

Сегодня утром установили новые 4-ех ядерные процессоры взамен 2-ух ядерных на сервере с мускулем и запустили ядро

Не думаю что это взаимосвязано... А раньше замеры делались? Может надежды не оправдались

Запрос к мускулю в любом случае не распараллеливается на ядра, а утм при запуске чего-то там чекает в сервисных связках, а потом уже запускает остальные потоки. При большом кол-ве пользователей это хорошо заметно.

zooxel · Сообщение **zooxel** » Ср янв 19, 2011 10:32

ds, ты видимо не понял всей ситуации. Дело не в том оправдались ли ожидания от скорости работы MySQL сервера, а в том, что старт ядра происходит очень медленно. Медленно он происходит не на этапе чеканий слинков, а именно на этапе установки всех соединений между ядром и БД. Слинки проверяются только после установки всех соединений.

Процессоры заменялись не для того, чтобы поднять скорость работы утм, которая и так вполне устраивала, а для других приложений и скриптов, скорость для которых например для операций SELECT увеличилась в 10 раз, т.е. увеличение производительности на лицо.

То, что в этом виновата смена процессоров очень сильно сомневаюсь, но что вызывало такой эффект пока понять не получается.

Обратите внимание на время между соединениями...

Info : Jan 18 07:28:50 UTM5 Logger: New `?Debug : ' stream: /noc/netup/log/utm5/debug.log
Info : Jan 18 07:28:50 UTM5 Logger: New ` Info : ' stream: /noc/netup/log/utm5/main.log
Info : Jan 18 07:28:50 UTM5 Logger: New `*CRIT : ' stream: /noc/netup/log/utm5/critical.log
?Debug : Jan 18 07:28:50 ModMap: Module <config> exist
?Debug : Jan 18 07:28:50 ModMap: Module <logger> exist
?Debug : Jan 18 07:28:50 ModMap: Module <rehash> exist
Info : Jan 18 07:28:50 DBA:Ctx: Creating 64 user DB connections
Info : Jan 18 07:28:50 DBA:Ctx: Creating 4 system DB connections
?Debug : Jan 18 07:28:50 DBCtx: Connecting to MySQL database
?Debug : Jan 18 07:28:50 DBCtx: Connection parameters username: XXX; dbname: UTM5 host: 192.168.101.2
?Debug : Jan 18 07:28:50 DBCtx: Setting database character set to <utf8>
?Debug : Jan 18 07:29:12 DBCtx: MySQL connection opened
?Debug : Jan 18 07:29:12 DBCtx: Connecting to MySQL database
?Debug : Jan 18 07:29:12 DBCtx: Connection parameters username: XXX; dbname: UTM5 host: 192.168.101.2
?Debug : Jan 18 07:29:12 DBCtx: Setting database character set to <utf8>
?Debug : Jan 18 07:29:25 DBCtx: MySQL connection opened
?Debug : Jan 18 07:29:25 DBCtx: Connecting to MySQL database
?Debug : Jan 18 07:29:25 DBCtx: Connection parameters username: XXX; dbname: UTM5 host: 192.168.101.2
?Debug : Jan 18 07:29:25 DBCtx: Setting database character set to <utf8>
?Debug : Jan 18 07:29:47 DBCtx: MySQL connection opened
?Debug : Jan 18 07:29:47 DBCtx: Connecting to MySQL database
?Debug : Jan 18 07:29:47 DBCtx: Connection parameters username: XXX; dbname: UTM5 host: 192.168.101.2
?Debug : Jan 18 07:29:47 DBCtx: Setting database character set to <utf8>
?Debug : Jan 18 07:30:00 DBCtx: MySQL connection opened
?Debug : Jan 18 07:30:00 DBCtx: Connecting to MySQL database
?Debug : Jan 18 07:30:00 DBCtx: Connection parameters username: XXX; dbname: UTM5 host: 192.168.101.2
?Debug : Jan 18 07:30:00 DBCtx: Setting database character set to <utf8>
?Debug : Jan 18 07:30:22 DBCtx: MySQL connection opened
?Debug : Jan 18 07:30:22 DBCtx: Connecting to MySQL database
?Debug : Jan 18 07:30:22 DBCtx: Connection parameters username: XXX; dbname: UTM5 host: 192.168.101.2
?Debug : Jan 18 07:30:22 DBCtx: Setting database character set to <utf8>
?Debug : Jan 18 07:30:35 DBCtx: MySQL connection opened
?Debug : Jan 18 07:30:35 DBCtx: Connecting to MySQL database
?Debug : Jan 18 07:30:35 DBCtx: Connection parameters username: XXX; dbname: UTM5 host: 192.168.101.2
?Debug : Jan 18 07:30:35 DBCtx: Setting database character set to <utf8>
?Debug : Jan 18 07:30:57 DBCtx: MySQL connection opened
?Debug : Jan 18 07:30:57 DBCtx: Connecting to MySQL database
?Debug : Jan 18 07:30:57 DBCtx: Connection parameters username: XXX; dbname: UTM5 host: 192.168.101.2
?Debug : Jan 18 07:30:57 DBCtx: Setting database character set to <utf8>
?Debug : Jan 18 07:31:10 DBCtx: MySQL connection opened
?Debug : Jan 18 07:31:10 DBCtx: Connecting to MySQL database
?Debug : Jan 18 07:31:10 DBCtx: Connection parameters username: XXX; dbname: UTM5 host: 192.168.101.2
?Debug : Jan 18 07:31:10 DBCtx: Setting database character set to <utf8>
?Debug : Jan 18 07:31:32 DBCtx: MySQL connection opened
?Debug : Jan 18 07:31:32 DBCtx: Connecting to MySQL database
?Debug : Jan 18 07:31:32 DBCtx: Connection parameters username: XXX; dbname: UTM5 host: 192.168.101.2
?Debug : Jan 18 07:31:32 DBCtx: Setting database character set to <utf8>
?Debug : Jan 18 07:31:45 DBCtx: MySQL connection opened
?Debug : Jan 18 07:31:45 DBCtx: Connecting to MySQL database
...

dk · Сообщение dk » Ср янв 19, 2011 10:47

http://dev.mysql.com/doc/refman/5.5/en/dns.html ?

zooxel · Сообщение **zooxel** » Ср янв 19, 2011 10:52

dk писал(а):http://dev.mysql.com/doc/refman/5.5/en/dns.html ?

Причем здесь это, если в логах видно же host: 192.168.101.2 и в таблицах прав у нас везде IP естественно, а не доменные имена.

dk · Сообщение dk » Ср янв 19, 2011 11:29

Внимательнее прочитайте, 1 и 2 абзац

zooxel · Сообщение **zooxel** » Ср янв 19, 2011 12:19

dk писал(а):Внимательнее прочитайте, 1 и 2 абзац

ну попробуем запустить вместе с --skip-name-resolve

Siny · Сообщение **Siny** » Чт янв 20, 2011 09:20

дамс ... странная ситуация
замена с2 на с4 выдала
select на +10х
dns на -10х
нужно взять на заметку -))

фри лучше конечно обновить до >=7stable, возможно в твоей версии устаревшие/кривые дрова переферии матери, в итоге замена процов так повлияла, в дальнейшем может еще где нить вылезти

zooxel · Сообщение **zooxel** » Чт янв 20, 2011 10:53

--skip-name-resolve действительно помог и соединения создаются моментально, однако неожиданно вылезли другие грабли и пришлось пока перезапуститься без этого параметра.

При попытке добавить нового юзера в Debug.log появились записи вида:
MySQL query failed:<There is no `yyy`@`xxx.lan` registered> Trying to reconnect: 0
MySQL query failed:<There is no `yyy`@`xxx.lan` registered> Trying to reconnect: 1
и т.д. и т.п.

Откуда ядро взяло xxx.lan, если везде указаны IP-адреса?

zooxel · Сообщение **zooxel** » Чт янв 20, 2011 12:15

Поняли в чем проблема была изначально. На dns-сервере для 192.168 не было обратной зоны, поэтому все и втыкало при поднятии соединений между ядром и БД.

А вот откуда трабла при использовании --skip-name-resolve пока не ясно ибо использование этой фичи для нас было бы очень полезным.

Siny · Сообщение **Siny** » Чт янв 20, 2011 13:31

а причем тут тогда

Сегодня утром установили новые 4-ех ядерные процессоры взамен 2-ух ядерных на сервере с мускулем и запустили ядро. Обнаружился непонятный эффект ...

)
зы это не вопрос ... скорее утверждение

zooxel · Сообщение **zooxel** » Чт янв 20, 2011 13:33

Банальное совпадение ... ядро не перегружали очень и очень давно.

ds · Сообщение ds » Пт янв 21, 2011 23:22

ds, ты видимо не понял всей ситуации. Дело не в том оправдались ли ожидания от скорости работы MySQL сервера, а в том, что старт ядра происходит очень медленно. Медленно он происходит не на этапе чеканий слинков, а именно на этапе установки всех соединений между ядром и БД. Слинки проверяются только после установки всех соединений.

Так и есть, отразил только замену процессоров