1. Споживання ресурсів, перший погляд
2. Мережа
3. Дискова підсистема сервера і SSD
4. Дискова підсистема клієнта і SSD
5. Оперативна пам'ять
6. процесор
7. висновки

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

В наших минулих публікаціях ми вже торкалися впливу продуктивності дискової підсистеми на швидкість роботи 1С, проте дане дослідження стосувалося локального використання програми на окремому ПК або термінальному сервері. У той же час більшість невеликих впроваджень припускають роботу з файлової базою по мережі, де в якості сервера використовується один з призначених для користувача ПК, або виділений файловий сервер на базі звичайного, найчастіше також недорогого, комп'ютера.

Невелике дослідження російськомовних ресурсів по 1С показало, що дане питання старанно обходиться стороною, у разі виникнення проблем зазвичай радиться перехід до клієнт-серверному або термінального режиму. А також практично загальноприйнятим є думка, що конфігурації на керованому додатку працюють значно повільніше звичайних. Як правило аргументи наводяться "залізні": "ось Бухгалтерія 2.0 просто літала, а" трійка "ледве ворушиться, безумовно, частка істини в цих словах є, тому спробуємо розібратися.

Споживання ресурсів, перший погляд

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

Для тестування ми взяли дві віртуальні машини під управлінням Windows Server 2012 R2 і Windows 8.1 відповідно, виділивши їм по 2 ядра хостового Core i5-4670 і 2 ГБ оперативної пам'яті, що відповідає приблизно середньої офісної машині. Сервер розмістили на RAID 0 масиві з двох WD Se , А клієнт на аналогічному масиві з дисків загального призначення.

У якості піддослідних баз ми вибрали кілька конфігурацій Бухгалтерії 2.0, релізу 2.0.64.12, яку потім поновили до 3.0.38.52, все конфігурації запускалися на платформі 8.3.5.1443.

Перше, що звертає на себе увагу, це виріс розмір інформаційної бази "трійки", причому істотно виріс, а також набагато більші апетити до оперативної пам'яті:

Ми вже готові почути звичне: "так чого вони там такого додали в цю трійку", але давайте не будемо поспішати. На відміну від користувачів клієнт-серверних версій, які вимагають наявності більш-менш кваліфікованого адміністратора, користувачі файлових версій вкрай рідко замислюються про обслуговування баз. Також рідко про це думають обслуговуючі (читай - оновлюють) ці бази співробітники спеціалізованих фірм.

Тим часом інформаційна база 1С - це повноцінна СУБД свого формату, яка теж вимагає обслуговування і для цього навіть є інструмент, який називається Тестування і виправлення інформаційної бази. Можливо злий жарт зіграло назву, яке ніби має на увазі, що це інструмент для усунення проблем, але низька продуктивність - теж проблема, а реструктуризація і реіндексація, разом із стисненням таблиць - добре відомі будь-якому адміністратору СУБД засоби оптимізації баз даних. Перевіримо?

Після застосування обраних дій база різко "схудла", ставши навіть менше "двійки", яку теж ніхто ніколи не оптимізував, також трохи зменшилось споживання ОЗУ.

Надалі, після завантаження нових класифікаторів і довідників, створення індексів і т.п. розмір бази виросте, в цілому бази "трійки" більше баз "двійки". Однак більш важливо не це, якщо друга версія задовольнялася 150-200 МБ оперативної пам'яті, то нової редакції потрібно вже полгигабайта і з цього значення слід виходити, плануючи необхідні ресурси для роботи з програмою.

Мережа

Пропускна здатність мережі - один найбільш важливих параметрів для мережевих додатків, особливо, як 1С в файловому режимі, які переміщують через мережу значні обсяги даних. Більшість мереж невеликих підприємств побудовані на базі недорогого 100 Мбіт / с устаткування, тому ми почали тестування саме з порівняння показників продуктивності 1С в мережах 100 Мбіт / с і 1 Гбіт / с.

Що відбувається при запуску файлової бази 1С по мережі? Клієнт викачує в тимчасові папки досить велика кількість інформації, особливо якщо це перший, "холодний", запуск. На 100 Мбіт / с ми очікувано впремося в ширину каналу і завантаження може зайняти значний час, в нашому випадку близько 40 секунд (ціна поділки графіка - 4 сек).

Другий запуск відбувається швидше, так як частина даних зберігається в кеші і знаходиться там до перезавантаження. Перехід на гигабитную мережу здатний значно прискорити завантаження програми, як "холодний", так і "гарячий", причому співвідношення значень при цьому дотримується. Тому ми вирішили висловити результат у відносних значеннях, взявши за 100% найбільше значення кожного виміру:

З викладеного вище графіків, Бухгалтерія 2.0 завантажується при будь-якій швидкості мережі вдвічі швидше, перехід зі 100 Мбіт / с на 1 Гбіт / с дозволяє прискорити час завантаження в чотири рази. Різниці між оптимізованої і неоптимізованою базами "трійки" в даному режимі не спостерігається.

Також ми перевірили вплив швидкості мережі на роботу в важких режимах, наприклад, при груповому перепроведенні. Результат також виражений у відносних значеннях:

Тут вже цікавіше, оптимізована база "трійки" в 100 Мбіт / с мережі працює з такою ж швидкістю, як і "двійка", а неоптимізованими показує вдвічі гірший результат. На гігабіт співвідношення зберігаються, неоптимізованими "трійка" також вдвічі повільніше "двійки", а оптимізована відстає на третину. Також перехід на 1 Гбіт / с дозволяє скоротити час проведення в три рази для редакції 2.0 і в два рази для 3.0.

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

Власне, для повсякденних завдань пропускна здатність мережі не є вузьким місцем, неоптимізованими "трійка" всього лише на 20% повільніше двійки, а після оптимізації виявляється приблизно настільки ж швидше - позначаються переваги роботи в режимі тонкого клієнта. Перехід на 1 Гбіт / с не дає оптимізованої базі ніяких переваг, а неоптимізованими і двійка починають працювати швидше, показуючи невелику різницю між собою.

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

Так чому ж 1С гальмує? Будемо розбиратися далі.

Дискова підсистема сервера і SSD

У минулому матеріалі ми домоглися збільшення продуктивності 1С розмістивши бази на SSD. Можливо недостатньо продуктивності дискової підсистеми сервера? Ми зробили заміри продуктивності дискової сервера під час групового проведення відразу в двох базах і отримали досить оптимістичний результат.

Незважаючи на відносно велику кількість операцій введення-виведення в секунду (IOPS) - 913, довжина черги не перевищила 1,84, що для дводискового масиву дуже хороший результат. Виходячи з нього можна зробити припущення, що дзеркала зі звичайних дисків буде достатньо для нормальної роботи 8-10 мережевих клієнтів в важких режимах.

Так чи потрібен SSD на сервері? Найкраще відповісти на це питання допоможе тестування, яке ми провели за аналогічною методикою, підключення до мережі всюди 1 Гбіт / с, результат також виражений у відносних значеннях.

Почнемо зі швидкості завантаження бази.

Може бути комусь і здасться дивним, але на швидкість завантаження бази SSD на сервері не впливає. Основний стримуючий фактор тут, як показав попередній тест, пропускна здатність мережі і продуктивність клієнта.

Перейдемо до перепроведення:

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

На повсякденних завданнях картина аналогічна:

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

Дискова підсистема клієнта і SSD

Вплив SSD на швидкість роботи локально встановленої 1С ми розбирали в попередньому матеріалі , Багато що зі сказаного справедливо і для роботи в мережевому режимі. Дійсно, 1С достатньо активно використовує дискові ресурси, в тому числі і для фонових і регламентних задач. На малюнку нижче можна бачити, як Бухгалтерія 3.0 досить активно звертається до диска протягом близько 40 секунд після завантаження.

Але при цьому слід усвідомлювати, що для робочої станції де активна робота проводиться з однією - двома інформаційними базами ресурсів продуктивності звичайного HDD масової серії цілком достатньо. Придбання SSD здатне прискорити деякі процеси, але радикального прискорення в повсякденній роботі ви не помітите, так як, наприклад, завантаження буде обмежуватися пропускною спроможністю мережі.

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

Оперативна пам'ять

Незважаючи на те, що оперативка зараз непристойно дешева, багато робітників станції продовжують працювати з тим обсягом пам'яті, який був встановлений при покупці. Ось тут і підстерігають перші проблеми. Уже виходячи з того, що в середньому "трійці" потрібно близько 500 МБ пам'яті можна припустити, що загального обсягу оперативної пам'яті в 1 Гб для роботи з програмою буде недостатньо.

Ми зменшили пам'ять системи до 1 Гб і запустили дві інформаційні бази.

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

До чого це призведе? Подивимося, як використовуються ресурси системи в важких операціях, наприклад, запустимо групове перепроведення відразу в двох базах. Спочатку на системі з 2 ГБ оперативної пам'яті:

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

Тепер зменшимо пам'ять до 1 ГБ:

Ситуація радикально змінюється, основне навантаження тепер припадає на жорсткий диск, процесор і мережа простоюють, чекаючи поки система вважає з диска в пам'ять потрібні дані і відправить туди непотрібні.

При цьому навіть суб'єктивна робота з двома відкритими базами на системі з 1 ГБ пам'яті виявилася вкрай некомфортною, довідники і журнали відкривалися зі значною затримкою і активним зверненням до диска. Наприклад, відкриття журналу Реалізація товарів і послуг зайняло близько 20 секунд і супроводжувалося все це час високої дискової активністю (виділено червоною лінією).

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

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

Недолік оперативної пам'яті - основна причина по якій робота з новими конфігураціями 1С виявляється некомфортною. Мінімально підходящими слід вважати конфігурації з 2 ГБ пам'яті на борту. При цьому враховуйте, що в нашому випадку були створені «тепличні» умови: чиста система, запущені тільки 1С і диспетчер задач. У реальному житті на робочому комп'ютері як правило відкриті браузер, офісний пакет, працює антивірус і т.д, і т.п., тому виходьте з потреби 500 МБ на одну базу плюс деякий запас, щоб при важких операціях ви не зіткнулися з нестачею пам'яті і різким зниженням продуктивності.

процесор

Центральний процесор без перебільшення можна назвати серцем комп'ютера, так як саме він, в кінцевому підсумку, здійснює обробку всіх обчислень. Щоб оцінити його роль ми провели ще один набір тестів, такий же, як і для оперативної пам'яті, зменшивши кількість доступних віртуальній машині ядер з двох до одного, при цьому тест виконувався два рази з обсягами пам'яті в 1 ГБ і 2 ГБ.

Результат виявився досить цікавим і несподіваним, більш потужний процесор досить ефективно брав на себе навантаження в умовах нестачі в ресурсах, в решту часу не даючи жодних відчутних переваг. 1С Підприємство (у файловому режимі) складно назвати додатком, який активно використовує процесорні ресурси, швидше за невибагливим. А в важких умовах на процесор лягає навантаження не стільки по обрахунку даних самого додатка, скільки обслуговування накладних витрат: додаткових операцій введення виведення і т.п.

висновки

Отже, чому гальмує 1С? В першу чергу це недолік оперативної пам'яті, основне навантаження в цьому випадку лягає на жорсткий диск і процесор. А якщо вони не блищать продуктивністю, як це зазвичай буває в офісних конфігураціях, то отримуємо ситуацію, описану на початку статті - "двійка" працювала нормально, а "трійка" безбожно гальмує.

На друге місце варто винести продуктивність мережі, повільний 100 Мбіт / с канал здатний стати реальним пляшковим горлечком, але в той же час режим тонкого клієнта здатний підтримувати досить комфортний рівень роботи навіть на повільних каналах.

Потім слід звернути увагу на дискову, покупка SSD навряд чи буде хорошим вкладенням грошей, а от замінити диск на більш сучасний буде не зайвим. Різницю між поколіннями жорстких дисків можна оцінити по наступного матеріалу: Огляд двох недорогих дисків серії Western Digital Blue 500 ГБ і 1 ТБ .

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

Сподіваємося даний матеріал допоможе вам швидше розібратися в питанні "чому гальмує 1С" і вирішити його найбільш ефективно і без зайвих витрат.