Dev ›
Как я обработку на альтернативный сервер выносил ›
#2
11.02.19 6:16
(1) Безусловно кластеризация 1С крутая штука, но попробую влить ложку дегтя. Если где-то буду не прав - исправьте меня.
1. Тот самый сервер, который сейчас я использую для того, что описано в посте, мы заказывали как раз для кластеризации. Была такая идея фикс улучшить производительность и отказоустойчивость. На деле, мы не ощутили значимого прироста в производительности, а вот в стабильности даже потеряли. В чем это проявилось? Наша база (конфигурация) обновляется минимум 1 раз в сутки, а бывает что 2-3 раза в сутки. (Вынуждены подстраиваться под бизнес очень динамично) Так вот, очень часто возникал баг, после обновления конфигурации, 1С переставала запускаться. Для фикса приходилось останавливать сервер приложений на обоих серверах, перезапускать SQL серверную службу, и лишь после этого все оживало. Это было накладно по времени, особенно в тех случаях, когда обновление необходимо сделать в рабочее время, и тут возникает такой глюк. В результате от кластеризации отказались.
(Тут конечно есть такой фактор как версия... Возможно в последней версии это исправлено, но мы, увы, ради стабильности не прыгаем на каждый новый релиз платформы во избежании испытывать на себе все новые баги. Ибо нас за это не похвалят. Поэтому, на текущий момент положение дел такое, что мы не используем кластеризацию по вполне объяснимым причинам.)
2. Помимо пункта 1, все таки, кластеризация - подразумевает распределение процессорной нагрузки и нагрузки по ОЗУ. Но при этом по прежнему БД остается тонким местом. И в моем примере, мой запрос вытягивает приблизительно от 3 до 5 млн записей (на текущий момент, но это количество неуклонно растет с каждым месяцем), затем часть этих данных распределяется по регистрам. Это хорошо если это все запущено ночью и лишь 2-3 человека в этот момент могут сидеть и получать тоже довольно увесистые отчеты. Но допустим бывают ситуации когда все же необходимо эту "мега обработку" запустить днем. Днем в базе работают все филиалы со всех городов. Все они дружно заключают договора, получают отчеты, тем временем из разных источников интеграционными методами в базу льются тысячи договоров и заключаются (проводятся) автоматически, что в общей массе создает не слабую очередь, периодические блокировки. Засим, выполнять мою "мега обработку", куда более приятно и спокойно, на отдельной базе данных, где будет работать только моя обработка.
p.s. У нас еще есть одна идея фикс, это сделать зеркалирование БД, и для отчетов использовать зеркало, а запись вести в основную базу (диск). Но тут тоже море подводных граблей, и как пишут опытные в этом деле люди, жизнь зеркалированной БД для 1С длится ровно до первой реструктуризации БД. И поэтому для нас это вообще не подходит) Слишком часто придется сталкиваться с лишними проблемами. Поэтому сложившихся условиях, то что описано в посте, очень помогает и разгружает наше решение. Но разумеется это не панацея и не в любых решениях будет оправдано.
