MySQL падает

[JEY70]

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

[rez0n]

Почитайте эту тему, в ней уже найдено много решений данной проблемы.

[viliam]

DigitalOcean
512m
1 cpu
CentOC+Vesa Panel
WordPress
===============


Банально не хватало ОЗУ :)
В первую очередь создал swap:

Code: Select all

dd if=/dev/zero of=/swapfile bs=1024 count=256k && mkswap /swapfile && swapon /swapfile && echo /swapfile          swap            swap    defaults        0 0 >> /etc/fstab

Потом оптимизировал nginx. Спасибо за решение от Visioner(viewtopic.php?f=32&t=3852&start=50#p6530), помогло.

В файлике /etc/nginx/nginx.conf изменил параметр worker_processes с 2 на 1, так как число должно быть равно количеству ядер в системе. Потом в секции http добавил строку:

Code: Select all

 limit_req_zone $binary_remote_addr zone=dyn:10m rate=10r/s;

Потом добавляем строку с ограничением для каждого своего домена в файле /home/username/conf/web/nginx.conf в начало секции location:

Code: Select all

limit_req zone=dyn burst=10;

Добавил так же строку с ограничением в шаблон nginx'a /usr/local/vesta/data/templates/web/nginx/default.tpl что бы последующие сайты создавались с правильными настройками:

Code: Select all

limit_req zone=dyn burst=10;

Перезагрузил nginx: service nginx restart

Вот результат:

Опционально можно установить кеширующие плагины (WP Super Cache) и/или завернуть на NS'ы cloudflare.com и кешировать там :)

[demian]

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

Для тех кто в танке: нехватка оперативной памяти получается из-за настроек mysql настройки по умолчанию очень сильно завышены даже для десятка сайтов на Вордпресс.
С учетом того что ядро mysqld при старте занимает 376 мегабайт оперативки. + по 4.5 мегабайта на 1 коннект получаем нехватку оперативки.

ядро мускула можно задавить до 48 мегабайт, а потребление на один коннект до 2 мегабайт в итоге получаем при лимите 100 коннектов 248 мегабайт на mysqld и 264 магабайта под все остальное снижение быстродействия 0, шаблоны: nginx - cache, индейец - hosting. 5-10 коннектов с секунду, в зависимости от плагинов к движку, сервер выдержит

[Lancaster]

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

Для тех кто в танке: нехватка оперативной памяти получается из-за настроек mysql настройки по умолчанию очень сильно завышены даже для десятка сайтов на Вордпресс.
С учетом того что ядро mysqld при старте занимает 376 мегабайт оперативки. + по 4.5 мегабайта на 1 коннект получаем нехватку оперативки.

ядро мускула можно задавить до 48 мегабайт, а потребление на один коннект до 2 мегабайт в итоге получаем при лимите 100 коннектов 248 мегабайт на mysqld и 264 магабайта под все остальное снижение быстродействия 0, шаблоны: nginx - cache, индейец - hosting. 5-10 коннектов с секунду, в зависимости от плагинов к движку, сервер выдержит

Я почитал ваши комментарии, и заметил из них, что все все делают не правильно. Может составите правильные конфиги для виртуалок с 512 ОЗУ, ну что бы вопросов не было?

[demian]

неоднократно писал и разъяснял что и для чего

еще раз конфиг mysql для 512мб, настраивался не для движка вордпрес+даже для используемого движка настройки завышены. Подойдет и для штук 10 разных сайтов на вордпрессе.

для начала

Code: Select all

# free -m
             total       used       free     shared    buffers     cached
Mem:           512        255        256          0          0        132
-/+ buffers/cache:        122        389
Swap:            0          0          0

из статистики awast от сайта

Code: Select all

Month	  Unique visitors	Number of visits	Pages	Hits	Bandwidth
May 2014	48,271	67,396	231,293	665,894	153.22 GB

Code: Select all

# mysql -V
mysql  Ver 14.14 Distrib 5.5.37, for Linux (x86_64) using readline 5.1

сам конфиг скула

Code: Select all

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
symbolic-links=0
max_connections=70
max_user_connections=30
wait_timeout=10
interactive_timeout=50
long_query_time=5

slow_query_log = 0 # дял включения лога установить 1
slow_query_log_file = /var/log/mysql-slow.log
long_query_time = 5
#log-queries-not-using-indexes

key_buffer_size = 16M
myisam_sort_buffer_size = 32M
join_buffer_size=1M
read_buffer_size=512k
sort_buffer_size=512k
table_cache=10k
thread_cache_size=128
max_allowed_packet=32M
max_connect_errors=1000
query_cache_limit=1M
query_cache_size=8M
query_cache_type=1
tmp_table_size=16M

#innodb_use_native_aio = 0
innodb_file_per_table
innodb_buffer_pool_size = 8M


[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

ну и наконец

Code: Select all

[--] Up for: 17d 11h 24m 30s
[OK] Maximum possible memory usage: 239.0M (46% of installed RAM)

ЗЫ: аптайм сбросился из-за перезагрузки для применения нового ядра, единственная перезагрузка с рестартом служб с момента запуска сервера. Серверу 5 месяцев.

ЗЫЫ:
хостинг: reg.ru
тариф: VPS-2
память: 512m
проц: 1 cpu
Виртуалка: openVZ
ОС: CentOC+Vesa Panel
Движок: самописка

[Lancaster]

demian

Спасибо!

А на счет тех конфигов для nginx, которые были составлены выше для защиты от F5, что скажите?

З.Ы. Пост выше можно в шапке закрепить.

[demian]

лучше крутить iptables чтобы не доходило до nginx и уж не дай бог до индейца

есть идея написания комплексного разветвленного конфига из кусков от разных проектов... но руки не доходят собрать все в кучу где нить и выставить для теста

от Ctrl+F5(организация ddos атаки в простонародье называемым "метод двух отверток" два компа сидящих на канале в 10мб каждый обычно валят 4 ядерный сервер с 16гигами оперативки) спасет только "бомба" - отправку соединения не в DROP илм REJECT, а в TARPIT или CHAOS, но сначало надо будет снять отслеживание соединения conntrack. Иначе сервер сам уйдет stackoverfoow. тогда атакующая система упадет сама, как только наберется 65636 открытых сокетов и это случится довольно быстро... а с учетом того что соединения TARPIT вешаются примерно на 30 минут можно будет не беспокоится

можете попробовать сами капнуть пока здесь https://www.rfxn.com/projects/advanced-policy-firewall/ и здесь https://www.rfxn.com/projects/brute-force-detection/

[filippoff]

demian

А на счет тех конфигов для nginx, которые были составлены выше для защиты от F5, что скажите?

З.Ы. Пост выше можно в шапке закрепить.

Не помогут. Сам сейчас озаботился защитой от F5, школьники одолели. С вышеприведённым шаманством VPS 2ГГц и 2Гб памяти ложится секунды за 4. Вопрос то серьёзный, фактически, получается, что любая случайность может сайты уронить.

[imperio]

У нас есть в планах создание шаблона с защитой от ddos. По срокам пока сказать не можем.