Активно развивающийся проект на платформе Битрикс 7.0 (Oracle версии 10.2.0.1, размер более 50 ГБ, Linux i386, выделенный сервер).
Предварительное замечание: этот сервер изначально был не совсем подготовлен для быстрой работы: 32-разрядная ОС на оборудовании x86_64, 32-битный Oracle, RAID-6 для файлов БД, 2 не самых быстрых (1.5 ГГц), зато 4-х ядерных процессора и 16 ГБ ОЗУ.
В связи с ростом нагрузки более чем в 2 раза с начала года - более 400,000 хитов в сутки, до 60,000 посетителей в сутки и после недавнего обновления на версию Битрикс 7.0 сайт стал испытывать определённые проблемы:
При load average 60 сайт удовлетворительно работал(что само по себе удивительно, Максим Смирнов искренне порадовался стабильности работы Linux+Oracle), при нагрузке 75 чувствовались проблемы.
Поскольку основную нагрузку создавали процессы Oracle, первым делом анализируем его.
Из отчётов AWR/statspack виясняем, что основное время пользовательские процессы вели активную "умственную" деятельность (CPU time):
Ну и поскольку мы видим, что на разбор SQL тратится совсем немного времени, менее 4% (%Non-Parse CPU: 96.29), а думать пользовательским процессам вообще говоря не о чем, кроме разбора и выполнения - ищем неэффективные запросы - с помощью тех же родных оракловских инструментов AWR/statspack выявляем самые ресурсоёмкие (по критериям SQL ordered by Elapsed Time, SQL ordered by CPU Time, SQL ordered by Gets) запросы и проверяем инилизационные параметры.
Проверяем ключевые параметры Oracle:
Проверяем системную статистику Oracle - никогда не собиралась, в этом случае это оправдано, т.к. используется 32-битный Oracle с ограничением SGA ~ 2,7 GB, т.е. наша БД активно использует кеш файловой системы и для неё операции физического чтения это чтение из кэша - в общем, "правды нет" и системная статистика тут вряд ли поможет.
Load_average ~ от 10 до 15
Проверяем httpd сервер:
Уже удовлетворительно, пробуем копнуть глубже, используем модуль Битрикс "Монитор производительности":
Что в результате?
Load_average ~ от 3 до 7
Средний % Idle CPU ~ 40-60% - это тот резерв, которого мы добивались!
С учётом появившегося резерва можно быть уверенным, что сайт выдержит планируемое 2-х кратное увеличение нагрузки.
P.S. Отражение результатов в статистике Oracle
Потребляемое нашей системой CPU time уменьшилось в 1,7 раза: с 8500 до 5000 секунд - система тратит меньше процессорных циклов вследствие оптимизации запросов
Количество операций чтения блоков (db file sequential read) уменьшилось более, чем в 5 раз
Многоблочное чтение (FULL SCAN'ы, db file scattered read) исчезли из TOP-5 - большая часть доступа к данным происходит по индексам
Операции, связанные с записью лог-файлов (log file sync, log file parallel write) незначительно увеличились количественно, что говорит о возросшем количестве транзакций (нагрузке), но продолжают быть достаточно медленными - 20 миллисекунд, это много, и является последствием использования RAID-6 для БД
Предварительное замечание: этот сервер изначально был не совсем подготовлен для быстрой работы: 32-разрядная ОС на оборудовании x86_64, 32-битный Oracle, RAID-6 для файлов БД, 2 не самых быстрых (1.5 ГГц), зато 4-х ядерных процессора и 16 ГБ ОЗУ.
В связи с ростом нагрузки более чем в 2 раза с начала года - более 400,000 хитов в сутки, до 60,000 посетителей в сутки и после недавнего обновления на версию Битрикс 7.0 сайт стал испытывать определённые проблемы:
При load average 60 сайт удовлетворительно работал(что само по себе удивительно, Максим Смирнов искренне порадовался стабильности работы Linux+Oracle), при нагрузке 75 чувствовались проблемы.
Поскольку основную нагрузку создавали процессы Oracle, первым делом анализируем его.
Из отчётов AWR/statspack виясняем, что основное время пользовательские процессы вели активную "умственную" деятельность (CPU time):
[FONT=Courier]Top 5 Timed Events Avg %Total ~~~~~~~~~~~~~~~~~~ wait Call Event Waits Time (s) (ms) Time ------------------------------ ------------ ----------- ------ ------ CPU time 8,511 73.6 db file scattered read 2,836,881 1,012 0 8.7 db file sequential read 2,452,163 606 0 5.2 log file sync 24,138 463 19 4.0 log file parallel write 26,075 283 11 2.4 --------------------------------------------------------------------- Instance Efficiency Percentages (Target 100%) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Buffer Nowait %: 99.98 Redo NoWait %: 100.00 Buffer Hit %: 94.95 In-memory Sort %: 100.00 Library Hit %: 98.75 Soft Parse %: 98.75 Execute to Parse %: 7.35 Latch Hit %: 99.90 Parse CPU to Parse Elapsd %: 86.79 % Non-Parse CPU: 96.29[/FONT] |
Ну и поскольку мы видим, что на разбор SQL тратится совсем немного времени, менее 4% (%Non-Parse CPU: 96.29), а думать пользовательским процессам вообще говоря не о чем, кроме разбора и выполнения - ищем неэффективные запросы - с помощью тех же родных оракловских инструментов AWR/statspack выявляем самые ресурсоёмкие (по критериям SQL ordered by Elapsed Time, SQL ordered by CPU Time, SQL ordered by Gets) запросы и проверяем инилизационные параметры.
Проверяем ключевые параметры Oracle:
- optimizer_features_enable = 10.2.0.1 [Ок]
optimizer_mode = ALL_ROWS [Ок, для версии 10.2.0.1]
optimizer_index_cost_adj = 100 [Ок]
optimizer_index_caching = 0 [Значение по умолчанию, предполагает, что для получения ЛЮБОГО индексного блока придётся выполнить операцию физического чтения с диска, не способствует индексному доступу к данным, увеличим до 90(%), для активизации использования индексов]
cursor_space_for_time = FALSE [Ок, в условиях ограниченной памяти для SGA]
session_cached_cursors = 50 [Мало, но некритически, рекомендуем увеличить до 150]
cursor_sharing = FORCE [Ок]
open_cursors = 300 [Ок]
Проверяем системную статистику Oracle - никогда не собиралась, в этом случае это оправдано, т.к. используется 32-битный Oracle с ограничением SGA ~ 2,7 GB, т.е. наша БД активно использует кеш файловой системы и для неё операции физического чтения это чтение из кэша - в общем, "правды нет" и системная статистика тут вряд ли поможет.
Load_average ~ от 10 до 15
Проверяем httpd сервер:
- apache.MaxRequestsPerChild = 500 - мало, процессы apache живут не более 3-5 минут, рекомендуем увеличить до 2500
apache.MaxClients = 100 - много для 8-ядерной машины, постоянно запущены от 50 до 60 процессов, рекомендует уменьшить до 30
Уже удовлетворительно, пробуем копнуть глубже, используем модуль Битрикс "Монитор производительности":
- 1. Настройки -> Производительность -> Очистка - удаляем старые данные
2. Настройки -> Производительность -> Включить - запускаем процедуру сбора данных на 1 минуту - процедура достаточно "тяжелая" для системы, желательно проверять загрузку системы во время выполнения.
3. Настройки -> Производительность -> Хиты с группировкой - с помощью фильтров можно выявить самые ресурсоёмкие страницы нашего Битрикс приложения, самые медленные запросы и планы выполнения запросов(!) - сам был приятно удивлён
Что в результате?
Load_average ~ от 3 до 7
Средний % Idle CPU ~ 40-60% - это тот резерв, которого мы добивались!
С учётом появившегося резерва можно быть уверенным, что сайт выдержит планируемое 2-х кратное увеличение нагрузки.
P.S. Отражение результатов в статистике Oracle
[FONT=Courier]Top 5 Timed Events Avg %Total ~~~~~~~~~~~~~~~~~~ wait Call Event Waits Time (s) (ms) Time ------------------------------ ------------ ----------- ------ ------ CPU time 5,041 80.9 log file sync 33,127 657 20 10.6 db file sequential read 482,404 379 1 6.1 log file parallel write 33,075 372 11 6.0 SQL*Net message to client 19,624,717 29 0 0.5 ---------------------------------------------------------------------[/FONT] |
Потребляемое нашей системой CPU time уменьшилось в 1,7 раза: с 8500 до 5000 секунд - система тратит меньше процессорных циклов вследствие оптимизации запросов
Количество операций чтения блоков (db file sequential read) уменьшилось более, чем в 5 раз
Многоблочное чтение (FULL SCAN'ы, db file scattered read) исчезли из TOP-5 - большая часть доступа к данным происходит по индексам
Операции, связанные с записью лог-файлов (log file sync, log file parallel write) незначительно увеличились количественно, что говорит о возросшем количестве транзакций (нагрузке), но продолжают быть достаточно медленными - 20 миллисекунд, это много, и является последствием использования RAID-6 для БД
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
