Тематический план

• 

  Общее

  • Новини Форум
  • Мокрієв М.В.
    

    Національний університет біоресурсів і природокористування України

    Оптимізація програмно-апаратного комплексу високонавантаженого навчального сайту

    Питання правильного підбору апаратного забезпечення та налаштування програмних компонентів для підтримання оптимальної продуктивності системи електронного навчання на базі системи Moodle — це одне з частих запитань на форумах підтримки та при замовленнях встановлення нової системи. Що потрібно, щоб наша система працювала ефективно.

    Частково на це питання є відповіді в документації [1],[2].
    

    Далі розберемося з рекомендаціями та порівняємо з реальним прикладом використання високонавантаженої системи в Національному університеті біоресурсів і природокористування України (НУБіП).
    

    Загальні характеристики кількості:
    всього користувачів в системі — 19325
    з них викладачів — 1378
               студентів — 17947
    відкрито курсів — 4117
    
    

    Об’єм жорсткого диску.

    Коротко читаємо: “Disk space: 200MB for the Moodle code, plus as much as you need to store content. 5GB is probably a realistic minimum.”[1] Тобто, на жорсткому диску нам потрібно передбачити як мінімум 200 Мб під власне систему (це без врахування операційної системи та ПЗ, яке нам необхідне для роботи системи). Реально буде більше в залежності від кількості додаткових модулів, яки ми вирішимо встановлювати. Так, в НУБіП програмний код moodle займає 238 Мб.
    

    Відведення дискового простору під файли курсів рекомендується починати з 5 Гб. При цьому повністю порожній курс займає 58 Кб. Скільки може займати місця один сформований курс буде залежати від кількості матеріалу в курсі та від типу матеріалів, які потрібно розмісти в курсі. В подальшому місце, яке займає курс на диску буде збільшуватися в залежності від кількості студентів на курсі та кількості різних робіт та діяльностей, які повинні виконувати ці студенти. Так, курс на один семестр підготовлений за вимогами НУБіП може займати 18 Мб. А цей же курс із зданими роботами 16 студентів, кожен з яких повинен здати 18 робіт в діяльність Завдання. вже займає 115 Мб. Отже, на одного студента можна розраховувати по 6 Мб. Проте, ця цифра приблизна, оскільки залежить від кількості файлів в кожній роботі, від типу файлів та ін.

    Найбільше місця на диску займають саме файли курсів. Але також потрібно враховувати і інші супутні дані: файли сесій користувачів, файли фото користувачів, кеш, тимчасові файли та ін. Всі ці дані збираються в каталозі moodledata.
    В НУБіП каталог  moodledata вже займає 4,8 Тб.

    Оскільки, ці дані є важливими для роботи системи і містять напрацьовані дані користувачів, їх бажано виокремити на інший диск. Також, причиною виокремлення цих даних є їхнє постійне зростання, що при переповненні диску може забрати місце необхідне для роботи операційної системи, що, в свою чергу, може повністю заблокувати роботу сервера та можливість потрапляння адміністратора в систему для виправлення ситуації.

    Також, при розрахунку об’єму диска потрібно враховувати об’єм бази даних. В НУБіП цей об’єм складає 134 Гб. Об’єм бази даних можна суттєво зменшити обмеживши журналювання подій. Так, в НУБіП журналювання налаштовано зі збереженням даних за 365 днів, і при поточній активності користувачів складає 58Гб в базі даних.

    Зменшення об’єму бази даних можна також досягти за допомогою періодичного очищення пройдених курсів (необхідно чітко визначити регламент та терміни зберігання даних навчання). При цьому, будуть видалятися файли студентів, спроби тестування, робота в інших діяльностях, оцінки та історія оцінювання (може бути взагалі виключена) тощо. Таким чином буде досягатися зменшення об’єму бази даних та каталогу moodledata.
    

    Отже, на об’єм диску суттєво буде впливати кількість створених курсів та кількість активних користувачів в системі, які в процесі навчання продукують контент.
    
    

    Процесори та оперативна пам’ять

    Наступною рекомендацією є “Processor: 1GHz (min), 2GHz dual core or more recommended” [1]. Необхідно розуміти, що процесор навантажується в процесі виконання операцій як інтерпретатором РНР, так і потужною роботою СУБД. І ця робота збільшується при одночасній роботі користувачів із системою.
    

    Цей же параметр випливає на об’єм оперативної пам’яті (RAM). В документації про RAM говориться “Memory: 512MB (min), 1GB or more is recommended. 8GB plus is likely on a large production server” [1]. Визначити чітку цифру для розрахунку доволі важко. Чим більше конкуруючих користувачів, тим RAM повинен бути більшим. Варто також дотримуватися рекомендації “If your system starts swapping, this is a sign that you need more RAM” [2]. При цьому, може виникнути ситуація, коли оперативної пам’яті вистачає, але не справляється центральний процесор.
    

    Цікаві рекомендації можна прочитати в одній з дискусій на сайті moodle.org , де стверджується, що “1920 одновременных пользователей - могут обслужить 2 четырёхядерных ксеона в гипертредингом (по два потока на ядро). При этом понадобится 16 потоков * 64 Мб = всего 1024 Мб оперативки.”[3]  Проте, реалії показують, що такі розрахунки не виправдовують себе. Оскільки один процес Apache може займати на себе понад 90 Mб (Рис 1.) і навіть до 100Мб - “Memory usage of apache process is usually 10MB but Moodle can easily use up to 100MB per process” [2]. 

    

    Отже, при 4Гб RAM відповідно формули
    
    MaxRequestWorkers = Total available memory * 80% / Max memory usage of apache process         [2]
    
    можемо очікувати одночасної роботи до 32 з’єднань (при тому, що 80% пам’яті віддається під apache). Враховуючи, що і 3, і 5, а інколи і 10сек., то за хвилину ми можемо очікувати до 400 користувачів. Понад це значення можна очікувати проблем.
    При збільшенні кількості одночасних користувачів варто дослухатися до наступної поради “Consider separate servers for the web "front ends" and the database” [1]. Такий розподіл надає можливість розподілити навантаження, а також точніше виявити вузькі місця в системі для їх усунення.

    Для цього варто слідкувати за серверною системою консольними засобами типу htop, atop, bashtop або їхніми аналогами.
    
    Розподіл навантаження між двома серверами виявив такі тенденції:
    1. на вебсервері основне навантаження лягає на процесор, тому цей ресурс потрібно збільшувати.
    2. оскільки файли системи розташовуються на вебсервері, то диски повинні бути достатнього об’єму. Але звертання но них не настільки часте, тож вони можуть бути на звичайних HDD. Проте, найбільша кількість читання/запису припадає на файли кешу та сесій, тож, при виявленні проблем з читанням/записом ці каталоги бажано винести на невеликий проте швидкий SSD.
    3. на сервері БД важливими компонентами стають оперативна пам’ять та швидкий диск.
    4. важливе постійне слідкування за системою, оскільки при достатній кількості RAM та швидкому диску, можна помітити, що перестає справлятися процесор.
    
    При розподіленні системи на два сервери вдалося досягти обслуговування понад 800 користувачів/хв. При цьому сервери мали 8 потоків ядра та 32Гб RAM. Проте, вже при такій кількості відчувалися проблеми зі швидкістю. Аналіз показав, що вузьким місце є процесорні потужності вебсервера, при тому, що оперативна пам’ять задіювалася не на повну (Рис.2, лів.). В той же час, сервер БД при тих же параметрах почувався не навантаженим (Рис.2, прав.).
    

    

    Враховуючи виявлені проблеми, вебсервер було перемішено на нові серверні потужності з 32 потоками ядра та 64Гб RAM. Це певні надлишкові потужності, проте саме такий сервер вже був у наявності. Розрахунок потужностей вказує на те, що ми можемо обслуговувати від 3 до понад 5 тис. користувачів. Проте тепер слабким місцем виявився сервер БД.

    На сервері БД було збільшено об’єм оперативної пам’яті до 64Гб. На такому сервері оперативної пам’яті бажано настільки багато, щоб можна було всю базу даних помітити в неї. Це надасть можливість СУБД швидко звертатися за даними. Тому, об’єм в 64Гб для нашої БД виявляється навіть не повністю достатнім. За допомогою налаштувань кешу innodb вдалося максимально заповнити RAM. Для цього параметр innodb_buffer_pool_size виставлено в 48G (75% від всього RAM) залишаючи решту під операційні потреби та кеш.
    Проте, наступна проблема, яку потрібно вирішувати — швидкість читання/запису на диск. В процесі роботи MySQL постійно читає з диску та пише туди. Розміщення значної частини бази в оперативну пам’ять частково вирішує цю проблему. Проте необхідний швидкий диск.

    В якості дика вибрати швидкий SSD і навіть два.  Об’єм їх може бути не дуже великим (256Гб вистачатиме в найвибагливішому варіанті).
    Для чого дисків два? На одному ми розміщуємо власне базу даних. На іншому — файли журналювання. В ці файли MySQL постійно скидає журнал транзакцій. Тому вони постійно знаходяться в запису. В стандартному налаштуванні — після кожної вдалої транзакції. Щоб зменшити кількість запису в ці файли можна встановити параметр скидання на диск innodb_flush_log_at_trx_commit в 0. Таким чином запис буде відбуватися лише раз в секунду.
    Виявилося, що в стандартному налаштуванні MySQL також пише окремі файли журналювання для реплікації даних. Оскільки, сервера для реплікації зараз не передбачається, цю функцію було виключено, що ще зменшило навантаження на дискову систему. Як результат зайнятість диску зменшилася до 80-90%.

    За поточними підрахунками отримана система може справитися з 1200-1400 конкурентних користувачів.

    Приріст в можливості обслуговування видно на графіку (Рис. 3)
    

    

    Проте, як видно з графіку, така система покликана забезпечити витримування  пікових навантажень — одночасну здачу екзаменаційних тестів в період сесії. В інший час кількість користувачів на сайті однакова.
    Для покращення такої ситуації також потрібно підключати організаційні можливості: розподілення екзаменів рівномірно протягом тижня та дня, формування тестового білету з видачею всіх питань на одній сторінці відразу, що зменшить кількість постійних звертань до сервера за кожним наступним запитанням.
    

    
    

    Список використаних джерел

    1. Документація. Встановлення Moodle. URL: https://docs.moodle.org/311/en/Installing_Moodle
    2.  Документація. Рекомендації щодо ефективності. URL: https://docs.moodle.org/311/en/Performance_recommendations
    3. Дискусія про технічні характеристики сервера. https://moodle.org/mod/forum/discuss.php?d=257234
  • Форум обговорення доповіді