Чому так повільно працює 1С 8.3. Гальма на файловій базі – як уникнути (з недавнього досвіду). Робота з нетиповими чи модифікованими версіями

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

Оптимізація за допомогою оновлення 1С

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

Багато хто давно користується можливістю автоматично оновити програму. Хоча це питання легко вирішується і вручну для 1с Підприємство 8.3, оновлення якого не завдасть клопоту.

Перший крок – завантаження останньої версії платформи, яка використовується зараз. Це робиться за допомогою диска ІТС, або через веб-інтерфейс, де займаються постійною підтримкою користувачів такої програми, як 1с Підприємство 8.3, оновлення конфігурації для якої також поставляється офіційно.

В останньому випадку архів з даними по оновленню завантажується окремо. Його розпакування відбувається в будь-якій папці, яка вважається найбільш зручною для користувача. Після цього потрібно запустити файл.exe. У наступному вікні просто натискаємо кнопку "Далі".

З'явиться ще одна сторінка. На ній користувач вибирає шлях, у якому установка завершується. Але цей крок рекомендується робити лише просунутим власникам персонального комп'ютера. Функцій за умовчанням зазвичай цілком вистачає на вирішення більшості проблем. За замовчуванням, в цьому випадку вказано одну папку, куди встановлюються всі оновлення. Це набагато зручніше, ніж коли кінцеві шляхи різні. Просто кілька разів натискаємо на кнопки "Далі" у програмі 1с Підприємство 8.3, оновлення конфігурації якої має проходити швидко.

Залишилася лише фінальна кнопка, яка й пропонує «Установку».

Як прискорити роботу 1С, якщо платформа гальмує

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

Оновлення версії 7.7

Конфігурація буває кількох типів. Залежно від цього вибирається перебіг подальших дій.

• Типові – у разі передбачається, що оновлення проводять й у регламентованої звітності.
• Типові галузеві зміни - багато в чому нагадують попередні варіанти. Важливо заздалегідь ознайомитись з інструкцією, яку пропонує розробник. Інакше потім не розібратися, чому 1с 8.3 вилітає під час оновлення.
• Модифіковані типові – у користувача завжди є можливість самому доопрацювати програму так, щоб вона відповідала поточним потребам. Ще один варіант розширення функціоналу – перехід на нові платформи. Наприклад, 8-ї версії.

Про версії 8.0 та 8.1

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

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

Що стосується версії 8.1, то до неї можна оновитися кількома способами:

1. вручну;
2. в автоматичному режимі;
3. звернення до фахівців компаній, що надають послуги у цій сфері.

Робота з нетиповими чи модифікованими версіями

Спочатку будь-яка конфігурація відноситься до типових розробок. Вона перестає бути такою, якщо на підприємстві вносять певні зміни. Наприклад, під час встановлення. Існують два класи, які виділяються у нетипових конфігурацій:

1. змінені;
2. створені з нуля, що враховують потреби конкретного підприємства.

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

Актуальність конфігурацій може підтримуватись такими діями:

• Коригування помилок.
• Розширення функціоналу.
• Вдосконалення.
• Зміна 1С 8.3, не оновлюється конфігурація у разі помилок в обслуговуванні.

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

• Треба пам'ятати, що не всі версії релізів можуть підходити до поточної конфігурації.
• Якщо оновлення не проводилися давно, можливо, доведеться завантажити кілька файлів або архівів.
• У списку легко зрозуміти, яка потрібна версія 1с Підприємство 8.3, оновлення вибирається самим користувачем.

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

Додаткові причини гальмування

Якщо програма оновлена ​​правильно і без будь-яких помилок, однак, 1С все одно гальмує, то причина може бути в наступному:

• Антивірус – при правильному налаштуванні жоден антивірус не заважатимемо системі, проте, якщо користуватися заводськими параметрами, то продуктивність 1С може знижуватися на 5-10%. Оптимізувати антивірус можна за допомогою додаткових налаштувань, прибравши фоновий режим (за крайньої потреби).
• Параметри комп'ютера - часто недостатньо потужні комп'ютери призводять до сильного зниження продуктивності 1С. Особливу увагу необхідно приділити відеокарті, оперативній системі та процесору.

Подібні методи дозволять значно оптимізувати та прискорити роботу в 1С для будь-якої компанії чи підприємства, після чого продуктивність програми значно підвищиться.

До нас часто приходять питання про те, що гальмує 1с, особливо при переході на версію 1с 8.3, дякуючи нашим колегам з ТОВ "Інтерфейс", ми докладно розповідаємо:

У наших попередніх публікаціях ми вже стосувалися впливу продуктивності дискової підсистеми на швидкість роботи 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С" і вирішити його найбільш ефективно і без зайвих витрат.

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

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

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

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

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

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

Як піддослідні бази ми вибрали кілька конфігурацій Бухгалтерії 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 навряд чи буде гарним вкладенням грошей, а ось замінити диск на сучасніший буде не зайвим. Різницю між поколіннями жорстких дисків можна оцінити за матеріалом: .

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

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

• Теги:

2. Особливість роботи програми. Часто навіть за оптимальних налаштувань 1С працює дуже повільно. Особливо сильно швидкодію падає, коли кількість одночасно працюючих з базою перевищує 4-5 користувачів.

Хто ви у компанії?

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

Пропускна спроможність мережі

Як правило, з однієї інформаційною базою(ІБ) працює не один, а кілька користувачів. При цьому постійно йде обмін даними між комп'ютером, на якому встановлений клієнт 1С і комп'ютером, на якому розташована ІБ. Обсяг цих даних досить суттєвий. Часто виникає ситуація, коли локальна мережа працює на швидкості 100 Мбіт/с, а це швидкість, що найчастіше зустрічається, просто не справляється з навантаженням. І знову користувач скаржиться на гальма у програмі.

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

Тепер давайте розглянемо кілька рішень проблеми з низькою швидкістю роботи 1С та їх вартість, на прикладі локальної мережііз 10 середніх комп'ютерів.

Рішення перше. Модернізація інфраструктури

Це, мабуть, найочевидніше рішення. Розрахуємо його мінімальну вартість.

Як мінімум, на кожен комп'ютер нам знадобиться планка оперативної пам'яті на 2 Гб, коштує в середньому 1500 руб, мережева картаза допомогою швидкості 1 Гбіт/c, коштує близько 700 руб. Додатково знадобиться щонайменше 1 маршрутизатор, що підтримує швидкість роботи 1 Гбіт/с, який обійдеться приблизно 4000 руб. Отже, вартість - 26000 рублів на обладнання, без урахування робіт.

В принципі, швидкість може суттєво зрости, проте тепер купувати в офіс недорогі комп'ютери вже не вийде. Крім того, дане рішенняне застосовується для тих, хто використовує Wi-Fi або хоче працювати через інтернет - у їхньому випадку швидкість мережі може бути в десятки разів нижчою. Напрошується думка: «А чи не можна реалізувати роботу програми повністю на одному потужному сервері, щоб комп'ютер не брав участь у складних розрахунках, а служив просто для передачі зображення?» Тоді можна працювати навіть на дуже слабких комп'ютерах, навіть у мережах із низькою пропускною здатністю. Природно, такі рішення існують.

Рішення друге. Сервер терміналів

Набув великої популярності ще за часів 1С 7. Реалізовано на серверній версії Windowsі чудово справляється з нашим завданням. Однак, має своє підводне каміння, а саме - вартість ліцензій.

Сама операційна системаобійдеться десь 40000 руб. Додатково до цього нам знадобиться для кожного, хто планує працювати в 1С ще ліцензія Windows Server CAL, вартістю приблизно 1700 руб і ліцензія Windows Remote Desktop Services CAL, яка коштує близько 5900 руб.

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

Рішення третє. Сервіс 1С Підприємства

Фірма 1С розробила своє вирішення цієї проблеми, здатне серйозно підвищити швидкість програми. Але тут є нюанс.

Справа в тому, що ціна такого рішення становить від 50 000 до 80 000 руб., Залежно від редакції. Для компанії до 15 користувачів виходить дорого. Великі надії покладалися на "міні-сервер 1С підприємства", який, за заявами фірми 1С, орієнтований на малий бізнес і коштує в районі 10000 – 15000 руб.

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

Як написав на форумі один програміст 1С: «Досі не зрозуміло, чому 1С обрала саме 5 підключень! Від чотирьох користувачів проблеми тільки починаються, а тут на п'яти все закінчується. Хочеш підключити шостого – доплати ще 50 тис. Зробили б хоч на 10 підключень…»

Звісно, ​​міні-сервер теж знайшов свого споживача. Однак для компаній, де з 1С працюють від 5 осіб, так і не з'явилося простого та недорогого рішення.

Крім описаних вище методів прискорення програми, існує ще один, що ідеально підходить для сегмента 5 - 15 користувачів, а саме - web-доступ для 1С у файловому режимі.

Рішення четверте. Web-доступ для 1С у файловому режимі

Принцип роботи наступний: на комп'ютері піднімається додаткова роль web-сервера, де відбувається публікація ІБ.

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

Таким чином, для роботи в 1С можна використовувати дуже слабкі машини, а пропускна здатність мережі ставати не критичною. Наші тести показали, що можна комфортно працювати через мобільний інтернетна дешевому планшеті, при цьому не відчуваючи дискомфорту.

Даний варіант поступається серверу 1С підприємства за швидкістю роботи, але ця різниця до 15-20 користувачів візуально практично не помітна. До речі, для реалізації web-сервера можна використовувати IIS (для Windows) та Apache (для Linux) і обидва ці рішення безкоштовні!

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

Не беруся стверджувати напевно, але швидше за все це пов'язано з двома причинами:

• Досить слабкий опис у технічній документації
• Знаходиться на стику відповідальності системного адміністратора та програміста 1С

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

Прискоримо 1С. Дистанційно, швидко та без вашої участі

Ми вміємо прискорювати 1Скі і при цьому не смикати замовника. Ми вникаємо в проблему, робимо свою роботу та йдемо. Якщо вам хочеться, щоб програма просто нормально працювала – зверніться до нас. Ми розберемося.

Залишіть заявку - та отримайте безкоштовну консультаціющодо прискорення програми.

Основна мета написання статті – щоб не повторювати очевидні нюанси тим адміністраторам (і програмістам), які ще не набрали досвіду з 1С.

Вторинна мета, якщо маю якісь недоліки, — на Інфостарті мені це вкажуть найшвидше.

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

На Інфостарті подібні статті є, у відповідних розділах ставитиму на них посилання (якщо пропущу щось - прохання підказати у коментарях, додам). Отже, припустимо у вас гальмує 1С. Як діагностувати проблему, і як зрозуміти, хто винен, адміністратор чи програміст?

Початкові дані:

Комп'ютер, що тестується, основний піддослідний кролик: HP DL180G6, в комплектації 2*Xeon 5650, 32 Gb, Intel 362i, Win 2008 r2. Для порівняння, порівнянні результати в однопотоковому тесті показує Core i3-2100. Обладнання спеціально взяв не найновіше, на сучасному обладнанні результати помітно кращі.

Для тестування рознесених серверів 1С і SQL, SQL Server: IBM System 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.

Для перевірки 10 Gbit мережі використовувалися Intel 520-DA2 адаптери.

Файлова версія. (База лежить на сервері в розшарованій папці, клієнти підключаються по мережі, протокол CIFS/SMB). Алгоритм за кроками:

0. Додаємо на файловий сервер тестову базу Гільова до тієї ж папки, що й основні бази. З клієнтського комп'ютерапідключаємось, запускаємо тест. Запам'ятовуємо результат.

Мається на увазі, що навіть для старих комп'ютерів 10-річної давності (Pentium на 775 socket ) час від натискання на ярлик 1С: Підприємство до появи вікна бази має пройти менше хвилини. ( Celeron = повільна робота).

Якщо у Вас комп'ютер гірший, ніж пентіум на 775 socket з 1 гб оперативної пам'яті, то я Вам співчуваю, та комфортної роботи на 1С 8.2 в файлової версіїВам буде важко. Подумайте або про апгрейд (давно пора), або про перехід на термінальний (або web, у разі тонких клієнтів та керованих форм) сервер.

Якщо комп'ютер не гірший, можна штовхати адміністратора. Як мінімум – перевірити роботу мережі, антивіруса та драйвера захисту HASP.

Якщо тест Гільова на цьому етапі показав 30 папуг і вище, але робоча база 1С все одно працює повільно - питання вже до програміста.

1. Для орієнтира, скільки ж може "вичавити" клієнтський комп'ютер, перевіряємо роботу тільки цього комп'ютера без мережі. Тестову базу ставимо на локальний комп'ютер(На дуже швидкий диск). Якщо клієнтському комп'ютері немає нормального ССД, то створюється рамдиск. Поки що найпростіше і безкоштовне — Ramdisk enterprise.

Для тестування версії 8.2 цілком достатньо 256 мегабайт рамдиска, і! Найголовніше. Після перезавантаження комп'ютера з працюючим рамдиском на ньому повинно бути вільно 100-200 мб. Відповідно, без рамдиска, для нормальної роботи вільної пам'яті має бути 300-400 мегабайт.

Для тестування версії 8.3 рамдиска 256 мегабайт вистачить, але вільної оперативної пам'яті треба більше.

При тестуванні слід дивитися на завантаження процесора. У випадку, близькому до ідеального (рамдиск), локальна файлова 1с під час роботи завантажує 1 ядро ​​процесора. Відповідно, якщо при тестуванні у вас ядро ​​процесора завантажено не повністю - шукайте слабкі місця. Трохи емоційно, але загалом коректно, вплив процесора працювати 1С описано . Просто для орієнтиру, навіть на сучасних Core i3 з високою частотою, цілком реальні цифри 70-80.

Найпоширеніші помилки цьому етапі.

а) Неправильно налаштований антивірус. Антивірусів багато, налаштування для кожного свої, скажу лише те, що при грамотному налаштуванні ні веб, ні касперський 1С не заважають. При налаштуваннях "за замовчуванням" - може забиратися приблизно 3-5 папуг (10-15%).

б) Режим продуктивності. Чомусь на це мало хто звертає уваги, а ефект – найвагоміший. Якщо потрібна швидкість - робити це обов'язково, і на клієнтських і на серверних комп'ютерах. (Гарний опис у Гільова . Єдиний нюанс, на деяких материнських платахякщо вимкнути Intel SpeedStep, то не можна включати TurboBoost).

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

Вмикати режим продуктивності можна (і бажано) у двох місцях:

Через BIOS. Вимкнути режими C1, C1E, Intel С-state (C2, C3, C4). У різних біосах вони називаються по-різному, але сенс один. Шукати довго, потрібно перезавантаження, але якщо зробив один раз – потім можна забути. Якщо BIOS все зробити правильно, то швидкості додасться. На деяких материнських платах налаштуваннями BIOS можна зробити так, що режим продуктивності Windows ролі не гратиме. (Приклади налаштування BIOSу Гільова). Ці налаштування здебільшого стосуються серверних процесорів або "просунутих" BIOS, якщо Ви таке у себе не знайшли, і у вас НЕ Xeon – нічого страшного.

Панель керування - Електроживлення - Висока продуктивність. Мінус - якщо ТО комптютера давно не проводилося, він сильніше гудітиме вентилятором, більше грітиметься і споживатиме більше енергії. Це – плата за продуктивність.

Як перевірити, що режим увімкнено. Запускаємо диспетчер завдань – швидкодія – монітор ресурсів – ЦП. Чекаємо, поки процесор нічим не зайнятий.

Це налаштування за замовчуванням. У BIOS C-state включені, режим енергоспоживання збалансований
У BIOS C-state включені, режим високої продуктивності Для Pentium та Core на цьому можна зупинитися, з Xeon ще можна вичавити трохи "папужок"
У BIOS C-state вимкнено, режим високої продуктивності. Якщо не використовувати Turbo boost - саме так має виглядати сервер, налаштований на продуктивність

Нині ж цифри. Нагадаю: Intel Xeon 5650, Ramdisk. У першому випадку тест показує 23.26, в останньому – 49.5. Різниця – майже дворазова. Цифри можуть змінюватись, але співвідношення залишається практично таким же для Intel Core.

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

в) Turbo Boost. Спочатку треба зрозуміти, чи підтримує Ваш процесор цю функцію, наприклад. Якщо підтримує, можна ще цілком легально отримати трохи продуктивності. (Питання розгону по частоті, особливо серверів, торкатися не хочу, робіть це на свій страх і ризик. Але погоджуся з тим, що підвищення Bus speed зі 133 до 166 дає дуже відчутний приріст як швидкості, так і тепловиділення)

Як включати turbo boost написано, наприклад, . Але! Для 1С є деякі нюанси (не найочевидніші). Складність у цьому, що максимальний ефект від turbo boost проявляється тоді, коли включені C-state. І виходить приблизно така картинка:

Зверніть увагу, що множник – максимальний, частота Core speed – найкрасивіша, продуктивність – висока. Але що буде в результаті з 1с?

А в результаті виходить, що за тестами продуктивності ЦПУ варіант з множником 23 попереду, за тестами Гільова у файловій версії - продуктивність з множником 22 і 23 однакова, а ось у клієнт-серверній - варіант з множником 23 жах жах (навіть, якщо C -state виставити на рівень 7, все одно повільніше, ніж з вимкненим C-state). Тому рекомендація, перевірте обидва варіанти у себе, та виберіть з них найкращий. У будь-якому випадку, різниця 49,5 та 53 папуги – досить значна, тим більше це без особливих зусиль.

Висновок – turbo boost включати обов'язково. Нагадаю, що недостатньо включити пункт Turbo boost у біосі, треба ще подивитися й інші налаштування (BIOS: QPI L0s, L1 – disable, demand scrubbing – disable, Intel SpeedStep – enable, Turbo boost – enable. Панель управління – Електроживлення – Висока продуктивність) . І я б таки (навіть для файлової версії) зупинився на варіанті, де c-state вимкнений, хоч там множник і менше. Вийде якось так...

Досить спірним моментом є частота пам'яті. Наприклад, ось частота пам'яті показується як дуже сильно впливає. Мої ж тести – такої залежності не виявили. Я не порівнюватиму DDR ​​2/3/4, я покажу результати зміни частоти в межах однієї лінійки. Пам'ять та сама, але у біосі примусово ставимо менші частоти.

І результати тестування. 1С 8.2.19.83, для файлового варіантулокальний рамдиск, для клієнт-серверного 1С та SQL на одному комп'ютері, Shared memory. Turbo boost в обох варіантах вимкнено. 8.3 показує порівняні результати.

Різниця – у межах похибки вимірювань. Я спеціально витягнув скрини CPU-Z щоб показати, що зі зміною частоти змінюються інші параметри, ті ж CAS Latency і RAS to CAS Delay, що нівелює зміну частоти. Різниця буде тоді, коли фізично змінюватимуться модулі пам'яті, з повільніших на швидші, але й там цифри не надто значні.

2. Коли з процесором та пам'яттю клієнтського комп'ютера розібралися, переходимо до наступного дуже важливого місця – мережі. Про тюнінг мережі написано багато томів книг, є статті на Інфостарті ( , та інші), тут я на цю тему загострюватиму увагу не буду. Перед початком тестування 1С прохання переконатися, що iperf між двома комп'ютерами показує всю смугу (для 1 гбіт карток – ну хоча б 850 мбіт, а краще 950-980), що виконані поради Гільова. Потім - найпростішою перевіркою роботи буде, хоч як це дивно, копіювання одного великого файлу (5-10 гігабайт) по мережі. Непрямою ознакою нормальної роботи в мережі в 1 гбіт буде середня швидкість копіювання 100 мб/сек, хорошої роботи — 120 мб/сек. Хочу звернути увагу, що слабким місцем (у тому числі) може бути завантаженість процесора. SMB протокол на Linux досить погано паралеліться, і під час роботи він цілком спокійно може з'їсти одне ядро ​​процесора, і більше не споживати.

І ще. З налаштуваннями по замовчуванням windowsклієнт найкраще працює з windows server(або навіть windows робочастанція) і протоколом SMB/CIFS, linux клієнт (debian, ubuntu інші не дивився) краще працює з linux і NFS (з SMB теж працює, але на NFS папуги вище). Те, що при лінійному копіюванні вин-лінукс сервер на НФС копіюється в один потік швидше, ще ні про що не говорить. Тюнінг debian для 1С - тема окремої статті, я до неї ще не готовий, хоча можу сказати, що у файловій версії отримував навіть трохи більшу продуктивність, ніж Win варіант на цьому ж обладнанні, але з postgres при користувачах понад 50 у мене поки що все дуже погано.

Найголовніше , про що знають адміністратори, що не "обпеклися", але не враховують початківці. Є багато способів задати шлях до бази 1с. Можна зробити \\server\share, можна \\192.168.0.1\share, можна net use z: \\192.168.0.1\share (і в деяких випадках такий спосіб теж спрацює, але далеко не завжди) і потім вказувати диск Z. Начебто всі ці шляхи вказують на те саме місце, але для 1С є тільки один спосіб, що досить стабільно дає нормальну продуктивність. Так ось, правильно робити треба так:

У командному рядку(або в політиках, або як Вам зручно) - робите net use DriveLetter: \\server\share. Приклад: net use m: \\server\bases. Я спеціально наголошую, НЕ IP адресу, а саме ім'ясервера. Якщо сервер на ім'я не видно - додайте його в dns на сервері, або локально до файлу hosts. Але звернення має бути на ім'я. Відповідно - у шляху до бази звертатися до цього диска (див. картинку).

А тепер я на цифрах покажу, чому саме така порада. Вихідні дані: Карти Intel X520-DA2, Intel 362, Intel 350, Realtek 8169. Win 2008 R2, Win 7, Debian 8. Драйвера останні, оновлення застосовані. Перед тестуванням я переконався, що Iperf дає повну смугу (крім 10 гбіт карток, там вийшло тільки 7.2 Gbit вичавити, пізніше подивлюсь чому тестовий сервер ще не налаштований як треба). Диски різні, але скрізь SSD (спеціально вставив одиночний диск для тестування, більше нічим не навантажено) або рейд із SSD. Швидкість 100 Мбіт отримана шляхом обмеження в налаштуваннях адаптера Intel 362. Різниці між 1 Gbit мідь Intel 350 і 1 Gbit оптика Intel X520-DA2 (отриманої шляхом обмеження швидкості адаптера) не виявлено. Максимальна продуктивність, турбобуст вимкнений (просто для сумісності результатів, турбобуст для хороших результатів додає трохи менше 10%, для поганих - взагалі може не позначитися). Версії 1С 8.2.19.86, 8.3.6.2076. Цифри наводжу не всі, а найцікавіші, щоб було з чим порівнювати.

Висновки (з таблиці та з особистого досвіду. Стосується лише файлової версії):

Через мережу можна отримати цілком нормальні цифри для роботи, якщо цю мережу нормально налаштувати, і правильно прописати шлях в 1С. Навіть перші Core i3 можуть давати 40+ папуг, що досить непогано, причому це не тільки папуги, в реальній роботі різниця теж помітна. Але! обмеженням при роботі кількох (більше 10) користувачів вже виступатиме не мережа, тут 1 Гбіт ще вистачить, а блокування при розрахованій на багато користувачів роботі (Гілев).

Платформа 1C 8.3 в рази вимогливіша до грамотного настроювання мережі. Базові налаштування- див Гілев, але врахуйте, що впливати може все. Бачив прискорення від того, що деінсталювали (а не просто відключали) антивірус, від прибирання протоколів типу FCoE, від зміни драйверів на старішу, але microsoft certified версію (особливо стосується дешевих карток типу асусів та довжин), від прибирання другої мережевої картки із сервера . Дуже багато варіантів, настроюйте мережу вдумливо. Цілком може бути ситуація, коли платформа 8.2 дає прийняті цифри, а 8.3 - у два чи навіть більше разів менше. Спробуйте грати з версіями платформи 8.3, іноді виходить дуже великий ефект.

1С 8.3.6.2076 (може і пізніші, точну версію ще не шукав) по мережі все-таки налаштувати простіше, ніж 8.3.7.2008. Домогтися від 8.3.7.2008 нормальної роботи по мережі (у порівнянних папугах) вдалося всього кілька разів, повторити для більш загального випадку не зміг. Сильно не розбирався, але судячи з онуч від Process Explorer там запис не так йде, як у 8.3.6.

Незважаючи на те, що при роботі на 100Мбіт мережі графік її завантаженості невеликий (можна сказати, що мережа вільна), швидкість роботи все одно набагато менше, ніж на 1 гбіт. Причина – затримки (latency) мережі.

За інших рівних умов (добре працюючої мережі) для 1С 8.2 з'єднання Intel – Realtek повільніше на 10%, ніж Intel-Intel. А ось realtek-realtek взагалі можуть дати різкі просідання на рівному місці. Тому, якщо є гроші - краще скрізь тримати мережеві картки Intel, якщо грошей немає - Intel ставити тільки на сервер (ваш К.О.). Та й інструкцій з тюнінгу інтелевих мережевих карток у рази більше.

Налаштування антивірусів за умовчанням (на прикладі drweb 10 версії) забирають близько 8-10% папуг. Якщо налаштувати як треба (дозволити процесу 1cv8 робити все, хоч це і не безпечно) – швидкість така сама, як і без антивірусу.

Лінуксовим гуру не читати. Сервер з samba це здорово і безкоштовно, але якщо на сервер поставити Win XP або Win7 (а ще краще – серверні ОС), то у файловій версії 1с працюватиме швидше. Так, і samba і стек протоколів і налаштування мережі та багато іншого в debian/ubuntu добре тюнінгується, але робити це рекомендується фахівцям. Немає сенсу ставити лінукс із налаштуваннями за замовчуванням і потім говорити, що він повільно працює.

Досить добре перевіряти роботу дисків, підключених через net use, з допомогою fio . Принаймні буде зрозуміло, чи це проблеми з платформою 1С, чи з мережею/диском.

Для одного користувача варіанта не можу придумати тести (або ситуацію), де була б видна різниця між 1Гбіт і 10 Гбіт. Єдине, де 10Гбіт для файлової версії дав результат краще – це підключення дисків по iSCSI, але це тема окремої статті. Все-таки вважаю, що для файлової версії 1 Гбіт карток достатньо.

Чому при 100 Мбіт мережі 8.3 працює помітно швидше за 8.2 - не розумію, але факт мав місце бути. Все інше обладнання, всі інші установки абсолютно однакові, просто в одному випадку тестується 8.2, а в іншому - 8.3.

Не тюнінгований NFS win-win або win-lin дає 6 папуг, у таблицю включати не став. Після тюнінгу 25 отримав, але нестабільно (розбіг у вимірах більше 2 одиниць). Поки не можу дати рекомендації щодо використання windowsта NFS протоколу.

Після всіх налаштувань і перевірок запускаємо знову тест з клієнтського комп'ютера, радіємо результату, що покращився (якщо вийшло). Якщо результат покращився, папуг стало більше 30 (а особливо більше 40), користувачів одночасно працює менше 10 а робоча база все одно гальмує - практично однозначно проблеми програміста (або Ви вже досягли піку можливостей файлової версії).

Термінальний сервер. (База лежить на сервері, клієнти підключаються по мережі, протокол RDP). Алгоритм за кроками:

0. Додаємо на сервер тестову базу Гільова до тієї ж папки, що й основні бази. З цього сервера підключаємося, запускаємо тест. Запам'ятовуємо результат.

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

2. Налаштування мережевих карток у разі термінального сервера мало впливає працювати 1с. Для забезпечення "особливого" комфорту, якщо у вас сервер видає більше 50 папуг можна погратися з новими версіями RDP протоколу, просто для комфорту роботи користувачів, швидшого відгуку та скролінгу.

3. При активній роботі великої кількості користувачів (а тут вже можна пробувати і 30 осіб на одну базу підключити, якщо постаратися), дуже бажано поставити SSD диск. Чомусь вважається, що диск не особливо впливає на роботу 1С, але всі тести проводять із включеним на запис кешем контролера, що неправильно. Тестова база маленька, вона цілком міститься в кеш, звідси й високі цифри. На реальних (великих) базах все буде зовсім інакше, тому для тестів кеш вимкнено.

Наприклад, перевірив роботу тесту Гилева з різними варіантами дисків. Диски ставив із того, що було під рукою, просто тенденцію показати. Різниця між 8.3.6.2076 та 8.3.7.2008 невелика (у варіанті Ramdisk Turbo boost 8.3.6 видає 56.18 а 8.3.7.2008 видає 55.56, в решті тестів різниця ще менша). Енергоспоживання - максимальна продуктивність, turbo boost вимкнено (якщо не сказано інше).

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

Для платформи 8.2 різниця у продуктивності між SATA та SSD варіантами - більш ніж удвічі. Це не помилка. Якщо під час тесту на CATA дисках дивитися на монітор продуктивності. то там очевидно видно "Активний час роботи диска (в%)" 80-95. Так, якщо включити кеш самих дисків на запис швидкість зросте до 35, якщо включити кеш рейд контролера - до 49 (незалежно від того, які диски тестуються зараз). Але це - синтетичні папуги кешу, у реальній роботі при великих базах ніколи не буде 100% write cache hit ratio.

Швидкість навіть дешевих ССД (я тестував на Agility 3) цілком вистачає для роботи файлової версії. Ресурс запису - інша справа, тут треба дивитися в кожному конкретному випадку, зрозуміло, що у Intel 3700 він буде на порядок вище, але там і ціна відповідна. І так, я розумію, що при тестуванні SSD диска я теж тестую переважно кеш цього диска, реальні результати будуть меншими.

Найправильнішим (на мій погляд) рішенням буде виділити 2 ССД диска в дзеркальний рейд для файлової бази (або кількох файлових баз), і нічого більше туди не поміщати. Так, при дзеркалі ССД зношуються однаково і це мінус, але хоча б від помилок електроніки контролера хоч якось застраховані.

Основні плюси ССД дисків для файлового варіанта з'являться тоді, коли буде багато баз і в кожній по кілька користувачів. Якщо баз 1-2 і користувачів в районі 10, то і SAS дисків вистачить. (але у будь-якому разі - дивитися завантаження цих дисків, хоча б через perfmon).

Основні плюси термінального сервера – у нього можуть бути дуже слабкі клієнти, і налаштування мережі на термінальний сервер впливають набагато менше (знову ваш К.О.).

Висновки: якщо на термінальному сервері запустити тест Гілєва (з того ж диска, де лежать робочі бази) і в ті моменти, коли гальмує робоча база, і тест Гільова покаже хороший результат (вище 30) - то в повільній роботі основний робочої базивинний, швидше за все, програміст.

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

Клієнт-серверний варіант.

Тести проводив лише з 8.2, т.к. на 8.3 все досить серйозно залежить від версії.

Для тестування вибирав різні варіанти серверів та мережі між ними, щоб показати основні тенденції.

Начебто всі цікаві варіанти розглянув, якщо щось цікавить ще – пишіть у коментарі, постараюся зробити.

САС на СГД працює повільніше, ніж локальні ССД, навіть незважаючи на те, що у СГД більші розміри кешу. ССД і локальні та на СХД для тесту Гільова працюють з порівнянною швидкістю. Якийсь стандартний багатопотоковий тест (не тільки записи, а всього обладнання), крім навантажувального 1С з ЦУП, я не знаю.

Зміна сервера 1С із 5520 на 5650 дала практично подвоєння продуктивності. Так, конфігурації серверів не збігаються повністю, але тенденцію показує (нічого дивовижного).

Збільшення частоти на сервері SQL, звичайно, дає ефект, але не такий, як на сервері 1С, MS SQL сервер відмінно вміє (якщо його про це попросити) використовувати багатоядерність і вільну пам'ять.

Зміна мережі між 1С та SQL з 1 гбіт на 10 гбіт дає приблизно 10% папуг. Чекав на більше.

Включення Shared memory ефект все-таки дає, хоч і не 15%, як описано. Робити обов'язково, благо це швидко та просто. Якщо хтось при установці дав серверу SQL іменований інстанс, то для роботи 1С ім'я сервера треба вказувати не FQDN (працюватиме tcp/ip), не через localhost або просто ServerName, а через ServerName\InstanceName, наприклад zz-test\zztest. (Інакше буде помилка СУБД: Microsoft SQL Server Native Client 10.0: Постачальник спільної пам'яті: Не знайдено бібліотеку спільної пам'яті, що використовується для встановлення з'єднання з SQL Server 2000 . state=1, Severity=10, native=126, line=0).

Для користувачів менше 100 єдиний сенс для рознесення на два окремі сервери - це ліцензія на Win 2008 Std (і старіші версії), яка підтримує лише 32 Гб ОЗУ. У всіх інших випадках - 1С і SQL однозначно треба ставити на один сервер і давати йому більше (хоча б 64 Гб) пам'яті. Давати MS SQL менше 24-28 Гб ОЗП - невиправдана жадібність (якщо Ви думаєте, що у Вас цієї пам'яті йому вистачає і все нормально працює - може Вам і файлової версії 1С вистачило?)

Наскільки гірше працює зв'язка 1С і SQL у віртуальній машині – тема окремої статті (підказка – помітно гірша). Навіть у Hyper-V все не так однозначно.

Збалансований режим продуктивності – це погано. Результати цілком корелюють із файловою версією.

У багатьох джерелах написано, що режим налагодження (ragent.exe -debug) дає сильне зниження продуктивності. Ну знижує, так, але 2-3% я не назвав би значним ефектом.