И снова к вопросу об оптимизации БД и поиске узкого места

cast KRoN73, образно говоря, мне нужна печь от которой можно плясать :-)

Посмотри цифры по sysbench. Типа такого скрипта:

#!/bin/bash

if [ "$(id -u)" != "0" ]; then
   echo "This script must be run as root" 1>&2
   exit 1
fi

SIZE=1000000
DB=TMP_SYSBENCH
USER=`cat /root/.my.cnf | grep ^user= | head -n1 | cut -d= -f2`
PASS=`cat /root/.my.cnf | grep ^password= | head -n1 | cut -d= -f2`
HOST=`cat /root/.my.cnf | grep ^host= | head -n1 | cut -d= -f2`

mysql -e "CREATE DATABASE $DB;"

RESULT_FILE=$(hostname)-$(date +%Y-%m%d-%H%M)-host-$HOST-big-complex-rw.txt
sudo mysql -e "SELECT @@version;" > $RESULT_FILE

echo "--- MAKE TEST -----------------------------------" >> $RESULT_FILE

echo Make test
/usr/bin/time sysbench --test=oltp --oltp-table-size=$SIZE \
        --mysql-db=$DB --mysql-user=$USER --mysql-password=$PASS --mysql-host=$HOST \
        prepare >> $RESULT_FILE 2>&1

echo "--- RUN  TEST -----------------------------------" >> $RESULT_FILE

echo Begin test
sysbench --test=oltp --oltp-table-size=$SIZE --mysql-db=$DB --mysql-user=$USER --mysql-password=$PASS --mysql-host=$HOST \
        --oltp-test-mode=complex --oltp-read-only=off \
        --max-time=30 --max-requests=0 --num-threads=8 run >> $RESULT_FILE

echo Cleanup
sysbench --test=oltp --oltp-table-size=$SIZE --mysql-db=$DB --mysql-user=$USER --mysql-password=$PASS  --mysql-host=$HOST cleanup

mysql -e "DROP DATABASE $DB;"

Процент более 30% и требуется увеличить параметры tmp_table_size (текущее значение: 128 МБ)

Ну, у меня в конфиге самого жирного сервера (оперативки — 32Гб, объём /var/lib/mysql — 49Гб) так:

# Значение по умолчанию 16 МБ, если вы не используете MEMORY таблиц,
# то установите это значение равным tmp_table_size.

max_heap_table_size = 2G

# tmp_table_size — максимальный размер памяти, выделяемой для временных таблиц,
# создаваемых MySQL для своих внутренних нужд. Это значение также
# ограничивается переменной max_heap_table_size, поэтому в итоге будет выбрано
# минимальное значение из max_heap_table_size и tmp_table_size, а остальные
# временные таблицы будут создаваться на диске. Значение по умолчанию зависит
# от системы, попробуйте установить его равным 32 МБ и понаблюдать за переменной
# состояния Created_tmp_disk_tables, ее значение должно быть как можно меньше.

tmp_table_size      = 2G

Временные таблицы на диске не показатель, они например для таблиц с text полями создаются всегда

Что может помочь это увеличение кешей ключей и innodb

Но начинать надо только точно выяснив где затык через те же iotop, htop, mysql slowquery

А так этого достаточно https://habrahabr.ru/post/108418/

Похоже, что в моём случае затык пока был не в базе, а в apache mpm-prefork :-D

Так как в Битрикс.ВебОкружение используется apache+nginx.

Подправил его параметры, посоздавал индексы и пока вроде неплохо, не тормозит.

За ответ спасибо, чуть позже сегодня изучу.

И, кстати, ты не знаешь в Битрикс этого года поддержки php7.0-fpm не завезли?

И, кстати, ты не знаешь в Битрикс этого года поддержки php7.0-fpm не завезли?

Нет, я Битрикс, вообще, только со стороны видел пару раз, не более :)

А думаешь, действительно, Апач может устраивать такой жор ресурсов при большой нагрузке, даже при том, что он стоит за nginx'ом?

А думаешь, действительно, Апач может устраивать такой жор ресурсов при большой нагрузке, даже при том, что он стоит за nginx'ом?

При тонкой настройке mpm-prefork раньше по производительности не сильно уступал nginx, а памяти хотя и жрал больше, но не критично на фоне той же БД. В отличие от, например, mpm-itk, который тормозил раз в 10.

Но это давно было, я много лет apache нигде не использую, так что не знаю, как оно сейчас :)

А как же mod_fcgid, отсюда WooCommerce + nginx +php-fpm (комментарий) ?

При тонкой настройке mpm-prefork раньше по производительности не сильно уступал nginx

Ну, может в каких то исключительных ситуациях, но вообще не совсем правда, по моему опыту.

Если клиенты «медленные» и их много (больше скажем пяти сотен одновременно, что не редкость для сайтов с фоточками), то апач просто выедает память, сервер начинает свопиться и, понятное дело, дико тормозить. С nginx поставленным перед префорком тот же самый сервер держал и значительно бОльшие нагрузки в общем-то имея неплохой запас по памяти. Правда потом мы упирались в дисковое чтение (картинки всё таки), но это уже кажется никакой заменой HTTP-сервера не исправишь. возились с разными кешами.. помогало в целом, ну и ssd.

Если клиенты «медленные» и их много (больше скажем пяти сотен одновременно, что не редкость для сайтов с фоточками), то апач просто выедает память

Ну, я не по своему опыту, но видел примеры очень убедительных тюнингов :) Но там, реально, настраивать очень много нужно, чтобы достичь производительности, сравнимой с nginx. И, конечно же, никаких .htaccess, что сразу обламывает 99% востребованности Апача :)

Под какую версию sysbench этот скрипт?

В sysbench 1.09 это не работает, там другие ключи и вообще эта версия не видит Percona 5.7.19-17 - Percona Server (GPL), Release 17, Revision e19a6b7b73f

Запустил тестовый скрипт на новой версии бенча.

У меня

total number of events:20556

Запускал с параметрами

/usr/bin/time sysbench  --rand-type=uniform /usr/share/sysbench/oltp_read_write.lua --table-size=$SIZE \
        --mysql-db=$DB --mysql-user=$USER --mysql-password=$PASS --mysql-socket=/var/lib/mysqld/mysqld.sock \
        --db-driver=mysql  prepare >> $RESULT_FILE 2>&1

Повторюсь sysbench 1.0.9

Что с пациентом? :-)

Что с пациентом? :-)

20k6 — нормально :)

Да ты и сам нашёл, что дело в Апаче.

Я просто чего тему апнул, может я скрипт запустил с хрен знает какими параметрами.

Т.е. вдруг у тебя старая версия, а у меня сейчас новая и попугаи несоизмеримы, я вот к чему.

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

Битрикс советует ставить innodb_pull_buffer_size от одной четверти до трети доступного ОЗУ.

А ты, что скажешь, сколько оптимально под нагруженный ИМ под ProxMox виртуалкой?

Просто разработчики Перкона в комментарии к конфигу советуют вот так

# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.

Новый битрикс работает на php7.0, но, конечно, не все шаблоны к нему адаптированы...

От 7 версии php есть ощутимый, по-моему, прирост.

Работает несколько магазинов на NGINX + PHP-FPM (7) + MySQL, без апача, основные тормоза наблюдаются из-за громоздких запросов к базе, с кучей джоинов и сортировок.

Imho, самый эффективный способ оптимизации битрикса, это упрощение запросов к базе. ну и конечно использование индексов в таблицах смотреть.

Но вообще 15К товара для ванильного битрикса, в 350 категориях, это не очень много. Однако мощности сервера

3 ядра Intel Xeon, 2 Gb RAM +SSD диск

вполне может не хватать.

У меня на одном из проектов 6 Гб оперативы, 4 ядра по 2ГГц... рассчитываю что будет достаточно для 50К позиций товара (без офферов и оптимизированной системой расчета скидок), однако вот уже сейчас на 20 тысячах притормаживает главная страница (конкретно - тормозит RAND-сортировка при выборке Хитов Продаж, Новинок...)

Уже съехали на дедик, увы, жручее поделие, печаль...

А ты memcached подключал к битриксу на 7-м пыхе?

Я подключил, вот так https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=32&LESSON_ID...

Но что-то не вижу признаков жизни, тоже тему создал, хотя кажись на тематическом форуме все деревянные — https://dev.1c-bitrix.ru/support/forum/forum6/topic102755/

Не, memcached не подключал

В php есть стандартный механизм кеширования php-opcache. Он по умолчанию юзается для прекомпиляции php-файлов.

А для кеша битрикса, я выделял tmpfs раздел (в fstab):

tmpfs /bxcache tmpfs nodev,nosuid,noatime,size=16G 0 0

и туда сливал (симлинками) все что битрикс пихает в

{www}/bitrix/cache/
{www}/bitrix/managed_cache/
{www}/bitrix/stack_cache/

Не знаю, насколько это эффективнее memcached, но пока что пашет...

Если будешь opcache включать, могут появиться глюки, когда PHP пытается выделить куеву тонну памяти, и крашится с ошибкой нехватики...

тут в конфиге opcache нужно увеличить значения параметров

opcache.memory_consumption=512
opcache.interned_strings_buffer=64

ну и конечно opcache.max_accelerated_files=100000 таким надо установить... сотня тысяч файлов!!! (всякого хлама))

Спасибо.

Пока подключил Redis для кеша битрикса — https://github.com/adlandh/bitrix-redis

И кеш сессий в memcached.

Правда ругается на то, что нельзя сохранять сессии без useragent и при импорте товара приходится возвращать сессии на файлах. Но пока не разбирался с этим.

И, кстати какое оптимальное значение max_input_vars в php.ini?

Для жирного ИМ.

А какая посещаемость/онлайн у магазина ?

Планируемая от 1000 уников/день, заказчик мечтает.

Детальный анализ не проводил, но точно зависит от шаблона, настроек и величины корзины.

я устанавливаю: max_input_vars = 10000

Вроде хватает.

Для теста, попробуй сотню товаров в корзину положить и оформить заказ, если пройдет, то после идешь в админку, меняешь цены (количества) у имеющегося в заказе товара, удаляешь парочку и добавляешь позиций 5... Если все ок, то менять параметр не нужно, если будут ошибки, то либо настройки корзины смотреть, либо настройки PHP, в том числе max_input_vars

У меня был опыт ~12-15K уников/день (онлайн под 100) на дедике, с переездами в разные дц плюс пара сайтов поменьше на нем же и Б24.

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

ps. Мне битрикс слона на ощупь напоминает, только с какой стороны не щупай, везде ж0па.