показать полностью
Пользователь 16965  -> Оптимизация веб-проектов
7 Сентябрь, 2010 10:40
Нестабильность Zend Server при большом количестве процессов Apache
Во время тестов (CentOS 5.5 32-bit, kernel 2.6.18-194, Zend Server CE 5.0.2, nginx, Apache/2.2.3, MySQL) второй раз наблюдаем, что при небольших и средних нагрузках оптимизатор Zend ведёт себя предсказуемо
"Opcode Caching is Up and Running"

а при увеличении нагрузки (кол-ве запросов/сек ~ 15-20, одновременных пользователей/сессий > 300) может отключаться:
"Opcode Caching Disabled"

При этом, естественно производительность веб сервера катастрофически падает (кроме нагрузки добавляется отсутствие кэширования). Такое поведение характерно при большом количестве допустимых дочерних процессов (child processes) Apache, параметр MaxClients >= 50
При уменьшении MaxClients до 20, этот негативный эффект (баг) пропадает и оптимизатор Zend Server (Optimizer +) продолжает успешно работать несмотря на нагрузку
Эффект описан на форуме Zend, пока безответно, но надеюсь, что разработчики заметят и исправят :)

P.S. Обращаю внимание, что описанный эффект характерен для действительно БОЛЬШИХ нагрузок (> 1 млн.хитов в сутки), и на то, что необходимость запускать более 20 процессов Apache возникает крайне редко
Александр
После установки bitrix_env.rpm, при каждом входе на сервер - табличка



Ну или правильнее пустить bitrix_env.rpm пятым пунктом
http://www.1c-bitrix.ru/products/vmbi...tions-link
Ban Dmitry
кол-ве запросов/сек ~ 15-20
необходимость запускать более 20 процессов Apache возникает крайне редко
20 запросов в секунду и MaxClients 20?
Очень стрёмно, если есть страницы, которые отрабатывают медленно, больше секунды. Тот же поиск, к примеру. 3-4 запроса к странице поиска, и здравствуй, 502 ошибка.
Usoltsev Igor
согласен, Дмитрий, что 20 MaxClients - не всегда достаточно, поэтому и описал эту "особенность"
а насчёт медленных поисковых запросов - пишите в ТП, такие проблемы нужно решать обязательно
*
 
*
показать полностью
Пользователь 16965  -> Виртуальные машины Битрикс
20 Ноябрь, 2009 13:33
Новая версия виртуальной машины VMBitrix 1.4
Выпущена новая редакция виртуальной машины VMBitrix 1.4
Прежде всего, заменено содержимое DOCUMENT_ROOT, теперь виртуальная машина комплектуется новым файлом bitrixsetup, что позволяет устанавливать новые продукты и редакции Битрикс, включая:
  • появившиеся редакции Корпоративного портала
  • новый продукт Портал органа власти
Исправлены ошибки и недочёты

Значительных изменений в настройках внесено не было, поэтому при небходимости обновления версии без скачивания и полной переустановки VMBitrix, например, для хостинг провайдеров, могу рекомендовать несложную shell процедуру замены содержимого папка /var/www:
# wget http://www.1c-bitrix.ru/download/vm/vm.tar.gz
# mv /var/www /var/www.0
# mkdir /var/www/
# cd /var/www/
# tar xzf ~/vm.tar.gz
# chown -R bitrix.bitrix /var/www

Внимание! Как указано выше, процедура предназначена только для новой VMBitrix 1.3, без установленного Битрикса, т.к. полностью заменяет (без возможности восстановления) содержимое DOCUMENT_ROOT (папка /var/www) на новое!
Т.е. если у вас уже установлен один из продуктов Битрикс на VMBitrix, то менять ничего не надо.
показать полностью
Пользователь 16965  -> Оптимизация веб-проектов
18 Ноябрь, 2009 10:48
Oracle готовит Unbreakable MySQL | LAMP сервер?
По сообщениям информированных источников, в течение Oracle OpenWorld (Oct. 11-15, San Francisco), активно обсуждались предположения о том, что Oracle готовится оснастить свой дистрибутив Linux (Oracle Enterprise Linux, коммерческое название инициативы Unbreakable Linux) приобретённой вместе с Sun СУБД MySQL — и получить таким образом достойное орудие против платформы Windows Server-SQL Server. Что-то типа Unbreakable Linux+MySQL сервер.

По заявлениям Ларри Эллисона [по крайней мере, до принятия Евросоюзом окончательного решения 25.11.2009] Oracle, имея за плечами согласие и поддержку Департамента юстиции США, не намерена оказываться от MySQL для получения согласования сделки по приобретению Sun от органов Европейского союза.

Во время своих выступлений на  Oracle OpenWorld совсем неслучайно и Ларри Эллисон (Larry Ellison), и сооснователь Sun Скотт Макнили (Scott McNealy) настойчиво говорили о том, что MySQL в гораздо большей степени соревнуется с MS SQL Server, чем с Oracle.

Согласно недавнему исследованию агенства Evans Data, более 50% разработчиков в странах с активно развивающимися рынками (emerging markets: Китай, Индия, Восточная Европа и Латинская Америка) используют Microsoft’s SQL Server, 46% – MySQL. Технологии Oracle в этом сегменте (Small Medium Business) используются куда менее активо.

Это рынок, на который Oracle нацеливает Unbreakable MySQL и на котором ожидается серьёзная борьба с Microsoft, с использованием маркетингового потенциала и опыта управления проектами Oracle. Кроме прочего, борьба может иметь идеологический оттенок: open source (LAMP) подход к разработке программного обеспечения против проприетарного подхода Microsoft.

Опыт работы с open source проектами у Oracle есть, и значительный: Linux, OCFS2, работы с PHP и др. проекты. С 2005 года Oracle владеет финской open source software компанией Innobase OY, разработчиком транзакционной технологии InnoDB, поставляемой и активно использующейся с MySQL. Активно развивается сотрудничество Oracle с компанией Zend: Zend Server теперь доступен через сеть Oracle’s Unbreakable Linux Network (напомню, что в продуктовой линейке Zend кроме платных есть прекрасный бесплатный продукт для оптимизации выполнения PHP – Zend Server CE). По этим шагам можно предположить, что Oracle давно и последовательно ведёт подготовку к запуску Unbreakable LAMP платформы.

В случае успеха эта стратегия позволит Oracle получить доступ (и, возможно, лидерство) к развивающемуся сегменту мелких и средних компаний - будущей клиентской базе - и в дальнейшем возможность продавать платные полнофункциональные продукты Oracle, по мере роста компаний и их потребностей.
Теги:
Шаромов Денис
Даёшь VMBitrix 1.0 на Unbreakable Linux! :)
показать полностью
Пользователь 16965  -> Виртуальные машины Битрикс
9 Ноябрь, 2009 11:39
О чём и для чего эта группа
Группа создана для обсуждения вопросов и проблем, возникающих при  установке и использовании виртуальной машины Битрикс, Битрикс AMI на Amazon EC2 и будущих проектов Битрикс в сфере виртуализации и облачных вычислений
показать полностью
Пользователь 16965  -> Оптимизация веб-проектов
16 Сентябрь, 2009 16:08
Критическая уязвимость в http-сервере Nginx
14.09.2009 23:23  Критическая уязвимость в http-сервере Nginx:
В web-сервере Nginx обнаружена удаленная критическая уязвимость (CERT VU#180065, CVE-2009-2629): переполнение буфера, которое может привести к выполнению произвольного кода с правами рабочих процессов или к осуществлению атаки "отказ в обслуживании" через передачу специальным образом сформированного URL.

Уязвимые версии: 0.1.0-0.8.14. С исправлением выпущены версии nginx-0.8.15, nginx-0.7.62, nginx-0.6.39 и nginx-0.5.38. Доступен патч и обновления для Debian, Fedora, FreeBSD. Ожидается в скором времени выход обновлений для RHEL, CentOS, OpenSUSE, SLES, Ubuntu, Gentoo, Mandriva и т.д. Информации о наличии эксплоита в публичном доступе пока нет.


В новой версии "Виртуальной машины Битрикс" 1.3 nginx обновлён до версии 0.7.62.
Теги:
Субботин Андрей
Это ссылка на старую. Сейчас - BitrixVirtualAppliance12.rar

А где BitrixVirtualAppliance13.rar?
Usoltsev Igor
Господа, немного терпения, закончим тесты - сразу вам отдадим!
показать полностью
Пользователь 16965  -> Оптимизация веб-проектов
7 Июль, 2009 14:24
Запросы MySQL в статусе state statistics
Проблема клиента Битрикс - долго выполняется запрос.
innotop показывает печальную картину:
CXN    When   Load  QPS     Slow  QCacheHit  KCacheHit  BpsIn    BpsOut
local  Now    0.00  286.87     0     68.14%     99.20%  279.27k   1.14M
local  Total  0.00  259.85     3     71.51%     99.08%  219.76k   1.44M

CXN     Cmd    ID      User      Host           DB            Time      Query
local   Query  132330  bitrix  192.168.0.1    bitrix  01:01:07  SELECT DISTINCT
local   Query  158219  bitrix  192.168.0.1    bitrix     12:37  SELECT DISTINCT

Попытаемся разобраться.
Версия MySQL не самая старая
mysql> select version();
+--------------------------+
| version()                |
+--------------------------+
| 5.0.32-Debian_7etch6-log |
+--------------------------+
1 row in set (0.00 sec)

Выясним, что это за долгоиграющий запрос и в каком статусе находится?
mysql> show full processlist;
...
| 132330 | bitrix | 192.168.0.1:45057 | bitrix | Query   | 3612 | statistics | 
SELECT DISTINCT BE.ID as ID,BE.NAME as NAME,BE.XML_ID as EXTERNAL_ID,BE.IBLOCK_ID as IBLOCK_ID,BE.IBLOCK_SECTION_ID as IBLOCK_SECTION_ID,B.DETAIL_PAGE_URL as DETAIL_PAGE_URL,BE.PREVIEW_PICTURE as PREVIEW_PICTURE, FPV1.VALUE as PROPERTY_MANUFACTURER_SRC_VALUE, FPV1.ID as PROPERTY_MANUFACTURER_SRC_VALUE_ID, FPEN2.VALUE as PROPERTY_STICKERS_VALUE, FPEN2.ID as PROPERTY_STICKERS_ENUM_ID, FPV2.ID as PROPERTY_STICKERS_VALUE_ID, FPV4.VALUE as PROPERTY_ARTICULS_VALUE, FPV4.ID as PROPERTY_ARTICULS_VALUE_ID, FPV5.VALUE as PROPERTY_RATE_VALUE, FPV5.ID as PROPERTY_RATE_VALUE_ID,L.DIR as LANG_DIR,BE.CODE as CODE,B.IBLOCK_TYPE_ID as IBLOCK_TYPE_ID,B.CODE as IBLOCK_CODE,B.XML_ID as IBLOCK_EXTERNAL_ID FROM b_iblock B      INNER JOIN b_lang L ON B.LID=L.LID      INNER JOIN b_iblock_element BE ON BE.IBLOCK_ID = B.ID INNER JOIN b_iblock_section_element BSE ON BSE.IBLOCK_ELEMENT_ID = BE.ID  INNER JOIN b_iblock_section BS ON BSE.IBLOCK_SECTION_ID = BS.ID  LEFT JOIN b_iblock_property FP1 ON FP1.IBLOCK_ID=B.ID AND  FP1.CODE='MANUFACTURER_SRC'  LEFT JOIN b_iblock_element_property FPV1 ON FP1.ID=FPV1.IBLOCK_PROPERTY_ID     AND FPV1.IBLOCK_ELEMENT_ID=BE.ID  LEFT JOIN b_iblock_property FP2 ON FP2.IBLOCK_ID=B.ID AND  FP2.CODE='STICKERS'  LEFT JOIN b_iblock_element_property FPV2 ON FP2.ID=FPV2.IBLOCK_PROPERTY_ID   AND FPV2.IBLOCK_ELEMENT_ID=BE.ID         LEFT JOIN b_iblock_property_enum FPEN2 ON FP2.ID = FPEN2.PROPERTY_ID AND FPV2.VALUE_ENUM=FPEN2.ID  LEFT JOIN b_iblock_property FP4 ON FP4.IBLOCK_ID=B.ID AND  FP4.CODE='ARTICULS'  LEFT JOIN b_iblock_element_property FPV4 ON FP4.ID=FPV4.IBLOCK_PROPERTY_ID   AND FPV4.IBLOCK_ELEMENT_ID=BE.ID  LEFT JOIN b_iblock_property FP5 ON FP5.IBLOCK_ID=B.ID AND  FP5.CODE='RATE'  LEFT JOIN b_iblock_element_property FPV5 ON FP5.ID=FPV5.IBLOCK_PROPERTY_ID        AND FPV5.IBLOCK_ELEMENT_ID=BE.ID  INNER JOIN b_iblock_property FP6 ON FP6.IBLOCK_ID=B.ID AND  FP6.CODE='MANUFACTURER'  INNER JOIN b_iblock_element_property FPV6 ON FP6.ID=FPV6.IBLOCK_PROPERTY_ID      AND FPV6.IBLOCK_ELEMENT_ID=BE.ID  INNER JOIN b_iblock_property FP7 ON FP7.IBLOCK_ID=B.ID AND  FP7.CODE='BIG_PHOTO'  INNER JOIN b_iblock_element_property FPV7 ON FP7.ID=FPV7.IBLOCK_PROPERTY_ID AND FPV7.IBLOCK_ELEMENT_ID=BE.ID        INNER JOIN b_iblock_property_enum FPEN7 ON FP7.ID = FPEN7.PROPERTY_ID AND FPV7.VALUE_ENUM=FPEN7.ID  INNER JOIN b_iblock_property FP9 ON FP9.IBLOCK_ID=B.ID AND  FP9.CODE='BIG_PLANS'  INNER JOIN b_iblock_element_property FPV9 ON FP9.ID=FPV9.IBLOCK_PROPERTY_ID       AND FPV9.IBLOCK_ELEMENT_ID=BE.ID        INNER JOIN b_iblock_property_enum FPEN9 ON FP9.ID = FPEN9.PROPERTY_ID AND FPV9.VALUE_ENUM=FPEN9.ID  INNER JOIN b_iblock_property FP11 ON FP11.IBLOCK_ID=B.ID AND  FP11.CODE='STABILIZATION'  INNER JOIN b_iblock_element_property FPV11 ON FP11.ID=FPV11.IBLOCK_PROPERTY_ID    AND FPV11.IBLOCK_ELEMENT_ID=BE.ID  INNER JOIN b_iblock_property FP12 ON FP12.IBLOCK_ID=B.ID AND  FP12.CODE='PHOTO_RESOLUTION'  INNER JOIN b_iblock_element_property FPV12 ON FP12.ID=FPV12.IBLOCK_PROPERTY_ID    AND FPV12.IBLOCK_ELEMENT_ID=BE.ID  INNER JOIN b_iblock_property FP13 ON FP13.IBLOCK_ID=B.ID AND  FP13.CODE='OPTICAL_ZOOM'  INNER JOIN b_iblock_element_property FPV13 ON FP13.ID=FPV13.IBLOCK_PROPERTY_ID       AND FPV13.IBLOCK_ELEMENT_ID=BE.ID WHERE 1=1  AND B.ID IN (0,21)         AND     (               (BE.WF_STATUS_ID=1 AND BE.WF_PARENT_ELEMENT_ID IS NULL)         ) AND (((BE.ACTIVE_TO >= now() OR BE.ACTIVE_TO IS NULL) AND (BE.ACTIVE_FROM <= now() OR BE.ACTIVE_FROM IS NULL)))  AND ((((BE.ACTIVE='Y'))))  AND ((((FPV6.VALUE_NUM = '218232')) OR ((FPV6.VALUE_NUM = '218235')) OR ((FPV6.VALUE_NUM = '218237')) OR ((FPV6.VALUE_NUM = '218238'))))  AND ((((FPEN7.VALUE LIKE 'ДА'))))  AND ((((FPEN9.VALUE LIKE 'ДА'))))  AND ((((FPV11.VALUE_ENUM = '1388'))))  AND ((((FPV12.VALUE >= '8'))))  AND ((((FPV13.VALUE >= '5'))))  AND ((BS.ID = 1481))


Интересно, что команда EXPLAIN для этого запроса выполняется так же долго и "висит" в том же состоянии.
Запрос сам по себе, конечно, жутковатый - объединение более 30 таблиц, но это не повод выполняться долго.

Важнее статус STATISTICS - наводит на грустные размышления... На сайте bugs.mysql.com находим упоминания об ужасных запросах Битрикс:
Bitrix's terible queries with multiple inner join parts
а также "оптимистичные" рассуждения о том, что Это не баг: для некоторых запросов ЛЮБАЯ DBMS может намного большее время в фазе оптимизации, чем выполнения.

К счастью там же упоминаются параметры, которые напрямую влияют на длительность фазы оптимизации запроса сервера MySQL. Один из них представляется важным в нашей ситуации optimizer_search_depth:

mysql> show global variables like 'optimizer_search_depth';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| optimizer_search_depth | 62    |
+------------------------+-------+


Установлено значение по умолчанию, попробуем уменьшить, как рекомендуется в документации MySQL и проверить на примере команды EXPLAIN:

mysql> explain select...
Query aborted by Ctrl+C
Empty set (4.90 sec)

прервал, всё по-прежнему долго

mysql> set session optimizer_search_depth=30;
Query aborted by Ctrl+C
Empty set (7.92 sec)

прервал, долго

mysql> set session optimizer_search_depth=10;
28 rows in set (0.22 sec)

намного лучше! Попробуем предоставить оптимизатору MySQL самому подобрать значение параметра:

mysql> set session optimizer_search_depth=0;
28 rows in set (0.03 sec)

Значит может, если захочет!
Странно то, что этот параметр по умолчанию установлен в значение 62 - можно даже предположить, что разработчики MySQL надеются успешно бороться с запросами о 60-ти таблицах %)

Оставляем optimizer_search_depth = 0, закрываем проблему.

P.S. Важные моменты:
1) Менять параметр при необходимости нужно на уровне сессии (не для всей системы) и проверять проблемный запрос:
mysql> [B]set session[/B] optimizer_search_depth=...;

В случае положительного результата можно попробовать выполнить с новым значением параметра типичные небыстрые запросы Битрикса, которые можно
получить из "Монитора производительности", чтобы убедиться, что изменение этого параметра не скажется отрицательно на производительности всей системы. И только после этого в период минимальной нагрузки (например, в 04:00 ;) можно попробовать изменить параметр для всей системы:
mysql> [B]set global[/B] optimizer_search_depth=...;

2) Описанная проблема не является багом Битрикса и сложные запросы тут ни при чём. Клиент сам выбирает базу данных, а MySQL - активно развивающийся продукт.
Жуков Евгений
Очень интересно! Спасибо!
показать полностью
Пользователь 16965  -> Оптимизация веб-проектов
26 Июнь, 2009 14:17
Проблемы с блокировками MySQL типа AUTO_INC: Битрикс невиновен
Активный бизнес проект на базе LAMP + Битрикс версии 8, десятки тысяч хитов в сутки. MySQL версии 5.032 Innodb, обычная нагрузка на сервер ~ 300 запросов в секунду.
Периодически требуется пакетная загрузка данных о товарах PHP-скриптом из CSV файла: 100-200 тысяч записей. Во время выполнения возникает ошибка:

  Deadlock found when trying to get lock; try restarting transaction

Клиент взволнованно спрашивает: "... скажите, импортировать в ИБ 170 тыс элементов это вообще проблема для Битрикса? Может ли это быть связано с переходом на 8ку?"

Два традиционных вопроса: кто виноват и что делать?
Семочкин Михаил
Этот INSERT выполняется 200 тысяч или один раз?
User 2000
Если через CIBlockElement::Add , то по всей видимости 200 тысяч раз (по одному на каждый элемент)
User 2000
При innodb_autoinc_lock_mode = 2 не будет работать репликация на основе бинарного лога... и айдишники не будут содержать последовательные значения. Т.е вместо 1-2-3 может быть 123-5445-45999 и т.д. Но это все мелочи, т.к по всей видимости репликации нет ни на одном битрикс проекте.  
показать полностью
Пользователь 16965  -> Оптимизация веб-проектов
20 Март, 2009 18:33
Вопросы производительности Битрикс
Последствия медленной отправки почты на производительность Битрикс, влияние использования постоянных соединений с БД (MySQL Innodb) на блокировки

Партнёры "Битрикс" готовят к запуску сайт с высокой ожидаемой посещаемостью и большой активностью по добавлению и модификации контента (инфоблоки).
Конфигурация: два выделенных сервера (для Веб и БД), в качестве БД использовалась MySQL с обязательным хранением таблиц в Innodb, учитывая планируемую нагрузку.

Предварительная конфигурация сайта, Apache и MySQL проводилась в соответствии с рекомендациями курса «Конфигурирование веб-систем для оптимальной работы» и активно используя "Монитор производительности" для диагностики "тяжёлых" страниц и запросов, мониторинга и настройки параметров БД (query_cache_size, tmp_table_size, max_heap_table_size, max_tmp_tables, table_cache и т.д.).
Однако, когда уже казалось, что сайт показывает хорошие результаты по производительности, проявились 2 неприятные проблемы:
  • периодически без системы возникающие ошибки вида MySQL Query Error: UPDATE b_stat_day SET ... [Lock wait timeout exceeded; try restarting transaction], и в этом случае все серверные процессы Apache оказывались блокированными, сайт блокирован до перезапуска MySQL.
  • непредсказуемое бессистемное замедление формирования отдельных страниц, которое проявлялось либо в большом времени формирования страниц - 30-60 секунд, либо даже ошибке 504 nginx timeout!
Начали разбираться с MySQL, мониторинг состояния производился командами:

  mysql> show full processlist;
  mysql> drop table if exists innodb_lock_monitor;
  mysql> CREATE TABLE innodb_lock_monitor (a INT) ENGINE=INNODB;
  mysql> SHOW ENGINE INNODB STATUS\G;
  mysql> DROP TABLE innodb_lock_monitor;


Выяснилось, что перед ошибкой, которую выводил PHP, в БД происходил deadlock на одних и тех же SQL-запросах типа

  INSERT INTO b_iblock_section_element...

Попытались решить проблему на уровне приложения - уменьшая количество одновременных вставок элементов инфоблоков - безрезультатно.
DEADLOCK этот довольно интересного типа insert intention waiting, описание которого можно посмотреть в багах MySQL. Возникает при множественных одновременных вставках в таблицу (как раз наш случай - активная работа с инфоблоками) и, по мнению специалистов MySQL, [как бы] багом вовсе не является, а есть правильное поведение MySQL+Innodb в определённых условиях. Ну да шут с ним ;)
Интереснее показалось нам другое: судя по диагностике блокировок Innodb (которая выводится в секции TRANSACTION команды SHOW ENGINE INNODB STATUS), всякий раз при возникновении проблем, блокирующей оказывалась транзакция с тем же OS thread id, что и транзакция, которую ранее MySQL выбирал в качестве "жертвы" при разборе DEADLOCK'а и должен был откатить. В подтверждение этого предположения, проблема с возникшими блокировками решалась силовым удалением "виновного" thread'а:

  MYSQL> kill thread_id

Бесплатная служба поддержки MySQL пока не сильно помогла нам в анализе причин происходящего :(

По совету Максима Смирнова, обратили внимание на используемое постоянное соединение с БД, которое могло быть причиной подобного поведения - см., например, обсуждение в блоге Peter Zaitsev Are PHP persistent connections evil ?. Для исключения каких бы то ни было проблем и учитывая, что в случае с MySQL новые соединения создаются быстро и незначительно влияют на общую производительность сайта, мы отключили постоянное соединение с БД:

  define("DBPersistent", false); в файле dbconn.php

Блокировки больше не проявлялись.

В это же время Денис Шаромов с Максимом Смирновым обнаружили похожую периодически возникающую проблему (nginx timeout) на другом сайте, связанную с медленной работой процедуры отправки почты.

Проверили на нашем проекте - 60 секунд на отправку сообщения!
Это и была причина появления обеих проблем: и Nginx timeout, и MySQL Lock! В первом случае связь очевидна, во втором - задержка отправки почтового уведомления на хите задерживала завершение транзакции по добавлению/модификации элемента инфоблока, дальше - заложенный в MySQL-Innodb DEADLOCK и, видимо, проблема с открытыми транзакциями и постоянными соединениями. Возникала проблема неожиданно, при обработке события отправки почты на хите.
Администраторы разобрались с почтой, обработка почтовых событий была перенесена на cron:

  1) define("BX_CRONTAB_SUPPORT", true); в dbconn.php
  2) добавить в crontab вызов php -f /..../bitrix/modules/main/tools/cron_events.php


Последнюю рекомендацию, с моей точки зрения, нужно применять на всех сайтах во избежание зависимости доступности сайта от работы службы почты. Либо постоянно мониторить скорость работы почты.
Теги:
Черкасов Евгений
Огромное спасибо за полезнейшие советы!


Скажите, пожалуйста, кто знает, не возникнут ли проблемы при запуске
php -f /..../bitrix/modules/main/tools/cron_events.php
раз в минуту по крону?

Бывает что отправляется по 5-10 тысяч писем за раз (подписка на новости).
Шаромов Денис
Проблем не будет.
Если прежняя отправка не закончилась - новая не будет инициирована.
Черкасов Евгений
Спасибо!
показать полностью
Пользователь 16965  -> Оптимизация веб-проектов
20 Ноябрь, 2008 16:48
Пример оптимизации "живого" проекта на платформе Битрикс
Активно развивающийся проект на платформе Битрикс 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):
[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 [Ок]
Анализирум-оптимизируем явно "медленные" запросы, достраиваем недостающие индексы на таблицах B_FORUM_PRIVATE_MESSAGE, B_IBLOCK_ELEMENTB_IBLOCK_SECTION_ELEMENT, B_STAT_* - скрипты для создания индексов отправляем разработчикам для включения в будущие релизы Битрикса.
Проверяем системную статистику 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
Load_average ~ от 8 до 12
Уже удовлетворительно, пробуем копнуть глубже, используем модуль Битрикс "Монитор производительности":

    1. Настройки -> Производительность -> Очистка - удаляем старые данные
    2. Настройки -> Производительность -> Включить - запускаем процедуру сбора данных на 1 минуту - процедура достаточно "тяжелая" для системы, желательно проверять загрузку системы во время выполнения.
    3. Настройки -> Производительность -> Хиты с группировкой - с помощью фильтров можно выявить самые ресурсоёмкие страницы нашего Битрикс приложения, самые медленные запросы и планы выполнения запросов(!) - сам был приятно удивлён
Таким образом с помощью "Монитора производительности" удалось выяснить основную причину проблем - неэффективные постраничные запросы, с выборкой и обработкой всего массива строк на стороне PHP, характерные для "старых" компонентов 1.0. Компоненты 2.0 формируют более оптимальный SQL код - в PHP возвращается из БД точно необходимое для отображения запрошенной станицы количество строк. Обновлённые запросы компонентов 2.0 также более эффективны с точки зрения производительности БД.
Что в результате?

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 для БД
Фото:
Дегтярёв Михаил
ИМХО, RAID 6 на нормальном контроллере помедленнее, чем RAID 5, но не настолько, как вы говорите.
Я так понял, что вас спас именно переход на компоненты 2.0? Код компонентов вы не меняли?
Usoltsev Igor
Я не сравниваю друг с другом RAID 6 и RAID 5, оба эти варианта для файлов БД не предназначены. Из уровней RAID для БД рекомендуется RAID 10, работающий предсказуемо быстро на любом оборудовании (контроллере).
В компонентах 2.0 используются оптимизированная обработка постраничных запросов и со стороны БД (более быстрые запросы), и со стороны PHP (обработка меньшего объёма данных). Снижается нагрузка и на БД, и на Веб - в посте просто приведён наглядный пример с точки зрения производительности системы.
Левый Иван
А у меня "Эксперт", и 15 сайтов в многосайтовой системе с тысячной посещаемостью каждый, которые очень даже активно нагружают сервер.

Монитор производительности очень бы пригодится, а покупать ради него "Бизнес" где есть только дополнительный интернет-магазин (который нам не нужен) совсем не хочется.

Интересно, можно ли модуль монитора аккуратно установить на проекте, потестировать, а потом удалить? :)

Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».