Падает сервер при нехватке ОЗУ

что говорит mysqltuner.pl ? no нужно смотреть как все работает и логи,

Какие именно логи смотреть / показать.

>> MySQLTuner 1.6.0 - Major Hayden
>> Bug reports, feature requests, and downloads
>> Run with '--help' for additional options and output filtering
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.5.47-MariaDB
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +ARCHIVE +Aria +BLACKHOLE +CSV +FEDERATED +InnoDB +MRG_MYISAM
[--] Data in MyISAM tables: 437M (Tables: 77)
[--] Data in InnoDB tables: 7G (Tables: 14)
[!!] Total fragmented tables: 25

-------- Security Recommendations -------------------------------------------
[OK] There is no anonymous account in all database users
[OK] All database users have passwords assigned
[!!] User 'ad@%' hasn't specific host restriction.
[!!] User 'el@%' hasn't specific host restriction.
[!!] User 'ff@%' hasn't specific host restriction.
[!!] User 'fo@%' hasn't specific host restriction.
[!!] User 'gr@%' hasn't specific host restriction.
[!!] User 'hyp@%' hasn't specific host restriction.
[!!] User 'ma@%' hasn't specific host restriction.
[!!] User 'pk@%' hasn't specific host restriction.
[!!] User 'va@%' hasn't specific host restriction.
[!!] User 'vo@%' hasn't specific host restriction.


-------- Performance Metrics -------------------------------------------------
[--] Up for: 4d 1h 51m 8s (11M q [32.328 qps], 260K conn, TX: 65B, RX: 1B)
[--] Reads / Writes: 98% / 2%
[--] Binary logging is disabled
[--] Total buffers: 2.9G global + 60.4M per thread (50 max threads)
[!!] Maximum reached memory usage: 3.6G (95.58% of installed RAM)
[!!] Maximum possible memory usage: 5.9G (154.35% of installed RAM)
[OK] Slow queries: 0% (73/11M)
[OK] Highest usage of available connections: 24% (12/50)
[OK] Aborted connections: 0.20% (525/260908)
[OK] Query cache efficiency: 23.3% (3M cached / 13M selects)
[!!] Query cache prunes per day: 15576
[OK] Sorts requiring temporary tables: 0% (505 temp sorts / 1M sorts)
[OK] Temporary tables created on disk: 1% (4K on disk / 216K total)
[OK] Thread cache hit rate: 99% (21 created / 260K connections)
[OK] Table cache hit rate: 114% (193 open / 168 opened)
[OK] Open file limit used: 21% (218/1K)
[OK] Table locks acquired immediately: 99% (11M immediate / 11M locks)

-------- MyISAM Metrics -----------------------------------------------------
[!!] Key buffer used: 20.4% (547M used / 2B cache)
[OK] Key buffer size / total MyISAM indexes: 2.5G/269.4M
[OK] Read Key buffer hit rate: 100.0% (88B cached / 33K reads)
[!!] Write Key buffer hit rate: 0.0% (39K cached / 39K writes)

-------- InnoDB Metrics -----------------------------------------------------
[--] InnoDB is enabled.
[!!] InnoDB buffer pool / data size: 128.0M/7.2G
[OK] InnoDB buffer pool instances: 1
[OK] InnoDB Used buffer: 100.00% (8191 used/ 8191 total)
[OK] InnoDB Read buffer efficiency: 99.71% (10400927972 hits/ 10430664047 total)
[!!] InnoDB Write buffer efficiency: 0.00% (0 hits/ 1 total)
[OK] InnoDB log waits: 0.00% (0 waits / 124568 writes)

-------- AriaDB Metrics -----------------------------------------------------
[--] AriaDB is disabled.

-------- Replication Metrics -------------------------------------------------
[--] No replication slave(s) for this server.
[--] This is a standalone server..

-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Restrict Host for user@% to user@SpecificDNSorIp
Reduce your overall MySQL memory footprint for system stability
Enable the slow query log to troubleshoot bad queries
Increasing the query_cache size over 128M may reduce performance
Variables to adjust:
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
long_query_time (<= 10)
query_cache_size (> 160M) [see warning above]
innodb_buffer_pool_size (>= 7G) if possible.

Каждая база весит от 0,5 до 1,5 Гб
 
вот тебе и ответ, сервак настроен неправильно, скорее всего вообще ненастроен,
INNODB база на 7 гигов и буферов на 60 мегов per thread ??
еще и MyISAM Key buffer size на 2.5G, нафига??
памяти всего 4гига...
у тебя еще и один CPU

тут все просто , если бюджет позволяет нужно нa больший сервак переезжать...
чистить базу и все настраивать правильно..
 
Оптимизаций никаких не проводилось
у тебя еще и один CPU.
Вообще конфиг 4 ядра 4 Гб

INNODB база на 7 гигов и буферов на 60 мегов per thread ??
Сколько поставить? 7 Гб ?

поставил
innodb_buffer_pool_size = 3G (отсутствовала запись)
key_buffer_size = 400M
 
по базе нада параметры настроить не только эти два

смотреть весь конфиг сервера, как он работает, смотреть логи.

ну и свап нужно оставить полюбому 2-4 гига
 
Да зачем менять вирутализацию, если человек говорит, что при увеличение памяти, сжирает все ресурсы, но скажем там KVM либо HyperV не будет убивать OOM процессы. нужно решать где в коде утечка памяти идет, и гуда стоько уходит, на крайняк если это все зависит от процессов httpd либо php прибивть их по крону раз в час. (но это костыль). В общем нужно анализировать проблему, перед тем как сразу менять хостера или виртуализацию.
 
Да зачем менять вирутализацию, если человек говорит, что при увеличение памяти, сжирает все ресурсы, но скажем там KVM либо HyperV не будет убивать OOM процессы. нужно решать где в коде утечка памяти идет, и гуда стоько уходит, на крайняк если это все зависит от процессов httpd либо php прибивть их по крону раз в час. (но это костыль). В общем нужно анализировать проблему, перед тем как сразу менять хостера или виртуализацию.
Вот в том-то и прикол, что php-fpm (настроен на ondemand) ест около 500 мб - 1500 мб . База - 6 Гб, nginx - 20 мб. А файл подкачки постепенно растет и растет.
 
Для начала посмотрите кто у вас уходит в свап. Для начала простым top, потом тыкае f и выбираем p. Появиться колонка с swap. Либо - в htop:
жмем f2, идем в columns, два раза в право, выбираем nswap и жмем f5. После определения того кто у нас такой прожорливый уже играем дальше

Так же советую попробовать - Mysqltuner перловский скриптец он даст не плохие рекомендации по оптимизации.
По крайней мере хуже не будет.
 
Последнее редактирование модератором:
Так же советую попробовать - Mysqltuner перловский скриптец он даст не плохие рекомендации по оптимизации.
По крайней мере хуже не будет.
Уже . Вопрос в том, что он рекомендует, например увеличить некоторые параметры до 7+ Гб, когда у меня озу всего 4 гб.

Для начала посмотрите кто у вас уходит в свап. Для начала простым top, потом тыкае f и выбираем p. Появиться колонка с swap. Либо - в htop:
жмем f2, идем в columns, два раза в право, выбираем nswap и жмем f5. После определения того кто у нас такой прожорливый уже играем дальше

zuH5XO2k.png

zuH5XO2l.png
 
Известная в европе поговорка — Pay peanuts get monkeys! Плати арахисом получай обезьянами.
Обычно неоптимизированные сервера средне тормозят, условно работают в два раза медленней, но не падают от загрузки — типо я покупаю сервер, ставлю из репозиториев стандартном стабильном софте, так мне еще нужно его тряпочкой протирать, фарами моргать, дверьми хлопать. На каких только движках в саппортах не поднимали вопрос о падении на OpenVZ. Это был и mudle — система дистантного образования, и Drupal — и тут Memory issues with Virtuozzo/OpenVZ, да что говорить, много много других стабильных систем — специально подчеркиваю данный факт!
Данная проблема с пресловутой формулировкой Out of memory длится с 2006 года, а некоторые тикеты в багрепортах до сих пор не закрыты.

К слову, тут есть такая статья Для просмотра ссылки Войди или Зарегистрируйся если у вас проблемы с языком, то можно почитать с переводчиком.
А подобных статей еще больше и судя по бесконечным коментариям в них, решать проблему оптимизацией не выходило, просто констатировали факт ухода оперативки и дальнейшим переездом кто куда от греха подальше. В общем мощно били в барабаны!
В сегменте рунета данный вопрос почти не поднимался, т.к. очень мало проектов с большими данными используют в среде виртуализации.

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

PS/ Проблема то в том, что вашу оперативку жрет перепроданный много раз сервер, и по факту у вас свободных 100-200 мегабайт — о чем вначале и говорили, это утечка!
 
Много раз сталкивался на виртуалках с такими же проблемами, оверселл серверов у хостеров - нормальное дело, особенно по памяти... Как-то на Magento словил такую же гадость в виде Out of memory.

Рекомендация одна - переезжай на железный сервак с виртуалки, там у тебя хоть гарантия есть, что твои 8-16Гб памяти реально твои :)
По ценникам на том же hetzner очень вкусно получается и за те же 20-30 евро в месяц ты получишь вполне адекватную железку начального уровня, а за 50 уже просто отличную.
Посмотри на ихнем аукционе серверов, там без сетап оплаты есть много предложений. Аукцион тут - Для просмотра ссылки Войди или Зарегистрируйся
Ценники от 27 евро идут еще VAT вернут еще, если не из ЕС заказываешь :) Т.е. реально от 25$ где-то будет сервер.
 
Назад
Сверху