MySQL вешает систему

Главные вкладки

Аватар пользователя sadad sadad 26 апреля 2010 в 22:08

Может и не совсем на тот сайт написал. Вопрос, вероятно, болше по ОС, чем по Друпал.

Беда возникла, а победить - ну никак. Сервер freebsd 7.2, apache 22, mysql, nginx

Машина 2 ГБ памяти, Intel 1600ГГц - 2 ядра.

В базе картотека примерно на 500 тысч записей. Возможность поиска записей по одному полю - заголовку.

Поиск организован напрямую через SELECT

Как только больше 100 человек одновременно - система встает в ступор. Уже перелопатил всю возможную инф по твик mysql, но ничего не помогает. Сам сервер, мне кажется на уровне железа должен держать эту нагрузку.

Сайт kremnik точка ru

Что делать? Может кто подскажет.

Комментарии

Аватар пользователя Ромка Ромка 26 апреля 2010 в 22:36

Индексы у таблицы есть? Вообще для таких объемов данных лучше прикрутить внешний поисковый движок, например Sphinx или Яндекс Сервер, о котором как раз сегодня пост был: http://drupal.ru/node/43489.

Аватар пользователя sadad sadad 26 апреля 2010 в 22:52

"Ромка" wrote:
Индексы у таблицы есть?

По всем, по которым в базе поиск: title nid vid ... и тд... + по всем связанным таблицам.

А sphinx и Я.сервер - думаете помогут, если база сама SQL SELECT выполнить не может. Сторонние сервисы - они теми же средствами пользуются. Я их даже ставить боюсь.

Аватар пользователя Ромка Ромка 26 апреля 2010 в 23:05

"sadad" wrote:
Сторонние сервисы - они теми же средствами пользуются.

Совсем нет. Как раз они-то свой собственный индекс создают, и, теоретически, ищут по нему гораздо быстрее чем MySQL по свои таблицам. Вот что в описании Сфинкса сказано:

  • high indexing speed (upto 10 MB/sec on modern CPUs)
  • high search speed (avg query is under 0.1 sec on 2-4 GB text collections)

С такими возможностями, думаю, Сфинкс пережует вашу базу очень шустро.

Аватар пользователя axel axel 26 апреля 2010 в 23:12

Вот прям именно конкретно 100 пользователей? Какой версии mysql? Раньше в mysql лимит max_connections был как раз 100 соединений, а в последних версиях - 150. Если это число превысить, то СУБД будет отказывать в обслуживании запросам сверх лимита. Поставьте скрипт mysqltuner или tunining-primer.sh и оцените параметры настройки СУБД, поправьте my.cnf в соответствии с рекомендациями. Либо обратитесь к специалисту.

Навскидку не зная загрузки системы судить сложно, но 100 одновременных коннектов на указанном железе на селектах выделенный mysql-сервер должен держать.

Аватар пользователя sadad sadad 27 апреля 2010 в 9:39

"axel" wrote:
Вот прям именно конкретно 100 пользователей? Какой версии mysql? Раньше в mysql лимит max_connections был как раз 100 соединений, а в последних версиях - 150. Если это число превысить, то СУБД будет отказывать в обслуживании запросам сверх лимита.

MySQL version 5.0.77

Не конкретно 100 пользователей... так... примерно сказал

max_connections - 200 установлено. У меня не отказ в обслуживании шел - просто ситема сдыхала. Вернее дела свои делала и просила ничем не отвлекать Smile

mysqltuner!!! еще кучу переменных и советов обозначил. Сделал, как предписано, теперь буду ждать наплыва посетителей Smile Но, кажется, что помогло.

Спасибо!!!

Если будет работать сфинкса еще прикручю.

Аватар пользователя axel axel 27 апреля 2010 в 11:18

sadad wrote:

MySQL version 5.0.77

Не конкретно 100 пользователей... так... примерно сказал

max_connections - 200 установлено. У меня не отказ в обслуживании шел - просто ситема сдыхала.

Так и пишите точней, не то в ответ наполучаете неправильных советов Smile Ок, значит дело не в connections. Один совет только: после mysqltuner и tuning-primer не меняйте в конфиге больше 1 параметра за раз. Это дольше, но всегда ясно какой параметр дал эффект.

Аватар пользователя sadad sadad 27 апреля 2010 в 12:06

Спасибо! Вроде система дышать начала, но буду ждать наплыва посетителей для проверки в реальных условиях.

Про mysqltuner и tuning-primer раньше не знал. Очень полезные утилиты для новичков типа меня.

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

Еще раз спасибо за советы.

Аватар пользователя sadad sadad 28 апреля 2010 в 11:16

Все без толку. Опять все то же самое. Система сдохла на 120 человеко-посетителях.

Попытался Сфинкс поставить, но он не пожелал работать черз pipe с больше 2000 записей. Правда если в .htaccess phpmemorylimit увеличить - то порог чуть увеличивается.

Аватар пользователя sadad sadad 29 апреля 2010 в 20:03

C мускулом разобрался... Методом тыка подобрал параметры. Но все не слава богу. Периодически начал получать от nginx сообщения "This web page is temporary disable". Выяснилось, что изначально апач22 виноват (или модуль при нем). Весь лог забит фразой [notice] child pid xxxxxx exit signal Segmentation fault (11). В общем все 33 несчастья. В результате страницы выводятся периодически обрезаанными, картинки наполовину, иногда вообще не грузятся, бывает, что тупо пхп код отдают. Теперь придется апач22 изучать досконально. Глабальное сношение и переустановка апач,мускл, пхп и пхп-экстешн результата не дали.

В итоге сайт работает, но вяло и с неохотой... на 3--

Большое спасибо всем откликнувшимся, но дальше уже придется самостоятельно разбираться. Потому как Segmentation fault от чего угодно быть может.