| Цитата |
|---|
| Алексей Власов пишет: у меня по дисковой системе |
зацените загрузку диска во время теста у меня....
и при этом 14 показывает:(
ниче не понимаю в этой жизни:oops:
|
Разработчикам |
Форум
низкая производительность системы
2. noatime был включен в экспериментах с виртуальным диском 3.и апц и еакселератор и даже memcached пробовал, результат +- 3 единицы одинаковый (свежая мысль пришла, надо их все вместе включить:)) то что они настроены и работают подтверждает сам битрикс |
|||
|
|
|
|
Алексей Власов, - теперь надо смотреть сам запрос, какие части таблицы с псевдонимом BE участвуют в "where" и дальше. У вас проблема в том, что
а) Mysql затрачивает кучу дисковых операций на выборку 261006 строк данных б) эти данные скорее всего настолько велики по объему, что при выборке создается временная таблица на диске. Т.е. сначала mysql читает с диска данные, потом туда опять их пишет, потом только отдаёт вам. Варианты дальнейших действий: 1. возможно переписать запрос, чтобы подвести как можно ближе под индексы, или индексы подвести под запрос - это может уменьшить цифру 261006 (самый "продвинутый" метод, если только возможен) 2. переписать запрос так, чтобы выбирались только нужные поля - тогда размер 1строки результата будет * 261006 - будет меньше, и может получиться обойтись без временных таблиц на диске. 3. примерно посчитать длину строки результата, умножить на 261006 - получиться примерно размер временной таблицы - разрешить создавать такие таблицы в памяти MySQL это параметры tmp_table_size = xxxM max_heap_table_size = xxxM НО возможно высчитанный xxxM будет неприлично велик для системы, всё зависит от размера памяти сервера update Судя по всему BE - это b_iblock_element. У меня длина строки таблицы - 3523 байта, при перемножении получается около 900МБ - примерно такой объем данных проворачивает ваш сервер при запросе. Потому вариант с tmp_table_size и max_heap_table_size получается неудачным. Если у вас на сервере оч.много памяти и таблица b_iblock_element в innodb, можно еще выставить большой innodb_buffer_pool_size может быть 2GB, может бльше, более точно подобрать можно по анализу отношения Innodb_buffer_pool_pages_free к Innodb_buffer_pool_pages_total - чем оно больше, тем дольше в кеше будет висеть b_iblock_element 4. использовать цифру из п.п.3, умножить в несколько раз и сделать такого размера диск в памяти, через tmpfs и указать её как папку для временных файлов MySQL 5. самый простой метод, если актуальность данных выборки не критично - делать выборку раз в XXX секунд по крону, сохранять её результат и показывать "из кеша", или же настроить кеш надолгое хранение выборки Oleg_, у меня отключение проактивного фильтра и * улучшило результат в 2 раза, с 14 до 28, APC и eAccelerator вместе - не дружат, а влияние memcached у меня на показатель оказалось невелико. Но вероятнее всего в реальном приложении memcached поможет больше. |
|
|
|
|
|
На сервере 8Гб памяти, для начала выставил innodb_buffer_pool_size 4Гб
tmp_table_size и max_heap_table_size --> 1Гб скорость работы отсталась на прежнем уровне. Да еще swappiness поставил 10 Скорость немного выросла после оптимизации таблиц через mysqlcheck -Aop Some conditions prevent the use of an in-memory temporary table, in which case the server uses an on-disk table instead: * Presence of a BLOB or TEXT column in the table так что таблицы на диске будут создаваться в любом случае |
|
|
|
|
|
Алексей Власов, - если силой забить не получается - надо что то делать с самим запросом. Присылайте, посмотрим )
А какие значения у вас Innodb_buffer_pool_pages_free Innodb_buffer_pool_pages_flushed Innodb_buffer_pool_pages_total после отработки этого скрипта? |
|
|
|
|
 |
|
|
|
|
|
Алексей Власов, неприятно, что pool не дал прироста. Тогда видимо можно спокойно уменьшить память для пула вдвое и для tmp_table до "разумных" цифр.
А вариант с tmpfs пробовали? Он как раз может обойти ограничение
Ну и запросик (вместе с cre ate table всех используемых страниц если они нестандартные + примерное число записей в них) глянуть можно? |
|||
|
|
|
|
вот и первые результаты подмонтировал диск tmpfs, объемом 2Гб
tmp_table -->128Мб innodb_buffer_pool_size --> 3Гб Производительность выросла до 22-23 и сайт стал заметно быстрее открываться, хотя все равно медленовато. странно, что df показывает, что диск в памяти пустой |
|
|
|
|
 ДЛя фс прописал noatime Вопросы на завтра среднее время отклика очень высокое + детально настрою nginx Посмотрим что получится Александру огромное спасибо за помощь ! |
|
|
|
|
|
Алексей Власов, пожалуйста, только не переусердствуйте с "объемами", у вас вроде 4GB ОЗУ было, и tmpfs в 2 + innodb_buffer_pool_size в 3 - это очень плохо при 4GB памяти....
|
||||
|
|
|
|||
