Прошу помощи в решении проблемы. Общие усилия команды + гугление не принесли результата спустя 2 недели попыток.
== Сервер ==
VPS timeweb.ru
CPU = 4 x 2,7 ГГц
RAM = 2 048 Мб
SSD = 20 Гб
VM Bitrix 4.3
Используется БУС Стандарт
Кол-во элементов (iblock_element) достигает под 100 тыс (35 тыс новостей, 40 тыс фото и остальной редкооткрываемый хлам)
Посещаемость сайта: 15 тыс уникальных посетителей
Используются стандартные компоненты, в основном news, news.list, news.detail.
Кеширование Авто + Управляемое везде, где можно
Установлен APC (стандарт в VMBitrix)
Таблицы innoDB
Таблица iblock_element весит 545 MB. Оптимизировать не удается.
Сайт в обычном состоянии находится в среднем значении нагрузки CPU 5-15%, в пики достигает 25%.
В какой-то момент CPU резко подскакивает до 100% (все 4 ядра в 100%) и сервер полностью вешается. Перегрузить его можно только вручную (принудительно). После такой перезагрузки приходится удалять файл mysqld.sock, оставшийся после ручной перезагрузки.
В http логах нет никакой аномальной активности
В messages указывается, что процесс mysqld был убит из-за out of memory (Killed process 3384 (mysqld) total-vm:2597328kB, anon-rss:1794008kB, file-rss:0kB).
В mysql логах множество строк:
InnoDB: Error: page X log sequence number 0 XXXXXXXXX
InnoDB: is in the future! Current system log sequence number 0 XXXXXXXXX.
что вполне логично, учитывая что сервер можно поднять только принудительным выключением.
Чаще всего (90%) проблема происходит после добавления новой новости. Но не сразу. Удается даже на фронтенде в нее зайти. Потом падает.
Настройки mysql подогнаны под рекомендации во вкладке perfmon_db_server.php
Пытались искусственно воссоздать падение сервера, проводя нагрузочное тестирование средствами битрикса ("масштабируемость" и добавляя новости + очищая весь кеш. Не получалось.
В самом начале добавили в таблице iblock_element индекс active. Формировать список новостей стал в 5 раз быстрее (с 30-60 сек до 5-7 сек)
== Сервер ==
VPS timeweb.ru
CPU = 4 x 2,7 ГГц
RAM = 2 048 Мб
SSD = 20 Гб
VM Bitrix 4.3
Используется БУС Стандарт
Кол-во элементов (iblock_element) достигает под 100 тыс (35 тыс новостей, 40 тыс фото и остальной редкооткрываемый хлам)
Посещаемость сайта: 15 тыс уникальных посетителей
Используются стандартные компоненты, в основном news, news.list, news.detail.
Кеширование Авто + Управляемое везде, где можно
Установлен APC (стандарт в VMBitrix)
Таблицы innoDB
Таблица iblock_element весит 545 MB. Оптимизировать не удается.
Сайт в обычном состоянии находится в среднем значении нагрузки CPU 5-15%, в пики достигает 25%.
В какой-то момент CPU резко подскакивает до 100% (все 4 ядра в 100%) и сервер полностью вешается. Перегрузить его можно только вручную (принудительно). После такой перезагрузки приходится удалять файл mysqld.sock, оставшийся после ручной перезагрузки.
В http логах нет никакой аномальной активности
В messages указывается, что процесс mysqld был убит из-за out of memory (Killed process 3384 (mysqld) total-vm:2597328kB, anon-rss:1794008kB, file-rss:0kB).
В mysql логах множество строк:
InnoDB: Error: page X log sequence number 0 XXXXXXXXX
InnoDB: is in the future! Current system log sequence number 0 XXXXXXXXX.
что вполне логично, учитывая что сервер можно поднять только принудительным выключением.
Чаще всего (90%) проблема происходит после добавления новой новости. Но не сразу. Удается даже на фронтенде в нее зайти. Потом падает.
Настройки mysql подогнаны под рекомендации во вкладке perfmon_db_server.php
Пытались искусственно воссоздать падение сервера, проводя нагрузочное тестирование средствами битрикса ("масштабируемость" и добавляя новости + очищая весь кеш. Не получалось.
В самом начале добавили в таблице iblock_element индекс active. Формировать список новостей стал в 5 раз быстрее (с 30-60 сек до 5-7 сек)