Рейтинг темы:
  • Голосов: 0 - Средняя оценка: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Медленная работа АСИОУ
#1
МОУ СОШ №56, г. Ярославль.

В нашей школе при работе с АСИОУ существует большая проблема: в то время, когда программой пользуется небольшое количество человек, АСИОУ работает нормально, но во время активной загруженности, практически не работает (списки классов не загружаются, отчёты не формируются, главная страница может совсем не открыться и т.д.). Мы обращались с этой проблемой в АСИОУ7: заменили в итоге ошибочные файлы и перенесли лишние уроки на лето прошлого года. Это результатов не дало. Специалист из ГЦРО переустановил нам АСИОУ на другой сервер, чтобы выяснить в чём проблема - в самой программе или в сервере. В итоге АСИОУ также не стала работать быстрее.

В АСИОУ7 нам сказали, что скорее всего проблема в том, что служба MySQL не оптимизирована под нашу систему. Где мы можем взять чёткую инструкцию по оптимизации работы MySQL под Windows?
Ответить
#2
Цитата:Где мы можем взять чёткую инструкцию по оптимизации работы MySQL под Windows?
В свое время нам настройку сделал Соколов (РИД). Если не изменяет память, был вручную отредактирован файл my в папке MySQL, увеличен ряд цифр. Инструкция тоже где-то "бродила" по форуму.
Ответить
#3
А не припомните, где примерно вы видели инструкцию? Не можем найти.

Ответить
#4
Вот инструкция от Сергея (последнее замечание про монтирование файловой системы касается исключительно Линукса и мне смысл его не понятен):



# Размер буфера ключей, можно ставить до 25% от общего объема ОЗУ, распределяется между всеми потоками. Для 4Гб ОЗУ мы ставим 256М

key_buffer_size = 256M



# Кэширование открытых ранее таблиц, 512 значение для 4Гб ОЗУ, при увеличении можно

# так же увеличивать (при необходимости, зависит от размеров кол-ва БД и кол-ва таблиц)

table_open_cache = 512



# От этих параметров зависит будет временная таблица создана в памяти или будет записана на диск. При превышении указанного размера, будет записана на диск.

# Иногда при больших запросах создается временная таблица для подготовки и сортировки результата

tmp_table_size = 64M

max_heap_table_size = 64M



# Буферы чтения, сортировки, значения для 4 Гб ОЗУ. При увеличении ОЗУ увеливать

# необходимо не пропорционально, например при 12 Гб ОЗУ, можно увеличить в 2 раза.

sort_buffer_size = 4M

read_buffer_size = 4M

read_rnd_buffer_size = 8M

myisam_sort_buffer_size = 64M



# Важный параметр, буфер для движка InnoDB, ставить надо максимально возможное значение, иp рекомендаций 50-80% доступного ОЗУ

innodb_buffer_pool_size = 1664M



Так же есть смысл монтировать раздел с БД с опцией noatime, при этом не будет записывать дата модификации файлов БД. Необходимо добавить данный параметр в fstab.

Ответить
#5
Продолжу тему про медленную работу АСИОУ.

Серверные мощности вполне себе хорошие: приложение крутиться на Xeon 2.4GHz 4Гб ОЗУ + MySQL на 8 cores Xeon 2.4GHz 8 Гб ОЗУ RAID0 из 2 SSD (запросы к СУБД отрабатывают быстро). Оба сервера находятся в пределах одной хост-машины, лаг сети - микросекунды.



Открываю вечером (когда я один пользователь) страницу с 30 сотрудниками и она генерится 3.5 секунды, что ооооочень долго для такого железа и софта. Картина повторяется стабильно. Данных пришло чуть менее 10Кб.

Дамп запросов к БД показал, что их было 1063. ТЫСЯЧА запросов для отображения 30 сотрудников! Не многовато ли?



Для анализа загрузки серверов увеличил число записей на странице и отобразил все (306 сотрудников). Страница генерилась уже 27 секунд (что вообще заоблачно) и весила 36 Кб. Дамп запросов показал, что на этот раз их было более 9200 (ничоси!!!). Загрузка сервера приложений была около 50-60% (пол ядра), а сервера СУБД - 5-7%.

8 тысяч из них были к таблице asiou_p_params, точно не вариант с кэшированием значений?



P.S. На каком же железе вы тестируете, что такое у вас проходит быстро?



P.P.S. С учётом того, что в таблице asiou_p_params у нас всего 664 строки и они занимают в MySQL 144Кб, можно просто их выбрать все и закэшить в памяти. А лучше сделать одну выборку с IN.



P.P.P.S. Зачем перечислять все поля в запросе (да ещё и с полным именем таблицы, когда она единственна), увеличивая длину запроса и время его парсинга, если можно указать звёздочку? Ведь даже если и есть одно неиспользованное поле, здесь оно потребует не так много накладных ресурсов ни извлечение и передачу.



P.P.P.P.S. Если всё-таки требуется сделать кучу однотипных запросов с изменённым одним параметром (как тут id), то правильный подход - это Prepared Statements.



Спасибо.
Ответить
#6
В Django я совсем не силён, из гугла добавил модуль для кэширования запросов ORM'а (johnny-cache) и теперь страница со всеми сотрудниками стала отдаваться за 12.5 секунд и делает всего 710 запросов к базе, теперь нагрузка на процессор сервера приложений отъело всё ядро. Но 12 секунд это тоже не очень идеально.
Ответить
#7
Цитата:теперь нагрузка на процессор сервера приложений отъело всё ядро
Вот это вообще не идеально.
Ответить
#8
dominusego Писал(а):Вот это вообще не идеально.

Как же не идеально, как раз же наоборот, это значит что нет простоев в ожидании ответа внешних данных. Не идеально только то, что это происходит очень долго.
Ответить
#9
Печать ведомостей по успеваемости вообще мрак.

По отделению строится за почти 2 минуты, производя около 24000 запросов к БД, ужас какой. Наверное у пользователей много терпения.



Решил немного посмотреть, как можно улучшить ситуацию. Я в питоне ещё новичок, а джанго увидел впервые, но несколько часов копаний позволили довести эти показатели на том же запросе до 14 секунд (в 8 раз) и почти 1500 запросов к БД (в 16 раз) (а ведь ещё есть потенциал по улучшению).



Интересно, разработчики читают данный форум? Если да, то могу поделиться своим результатом.

Ответить
#10

очень бы хотелось, чтобы разработчики взяли эти результаты. У пользователей ооочччеееннь много терпения. Но сейчас это можно назвать реактивной скоростью по печати ведомостей, вот раньше было... "Блиц-Блиц, скорость без границ".
Ответить


Переход:


Пользователи просматривают эту тему: 1 Гость(ей)