Разбор ошибок конфигурации MS SQL Server под 1С
Новый сервер за три миллиона уже ехал к заказчику, когда я впервые открыл мониторинг старого.
Система замирала каждый час. Отдел сопровождения перебрал десяток версий, руководство устало ждать и решило вопрос привычным способом - купить железо помощнее.
За неделю до приезда новой машины я снял метрики со старой. Сервер приложений 1С стоял на одной машине с СУБД. Всё хозяйство лежало на диске C. Настройки - по умолчанию, до последнего флага. Ежечасные фризы создавало регламентное задание, которое франчайзи забыли отключить.
Старый сервер заработал без сбоев раньше, чем приехал новый.
У этой истории есть слой глубже. Сервером СУБД в типичной компании занимаются системный администратор и 1С-специалист, каждый со своей стороны, а уровень базы данных остаётся между их компетенциями. Когда компания строит электроподстанцию, никому не приходит в голову сказать «у нас есть штатный электрик, он справится». С сервером, через который проходят все продажи и вся отчётность компании, поступают ровно наоборот. Платят за это простоями в пиковые дни, зависшими отгрузками и авральными закупками железа, которое не решает проблему. DBA и есть тот профильный инженер: единственный, кто на вопрос «почему тормозит и где именно» отвечает цифрами вместо версий.
Из таких историй собралась статья - первая часть разбора ошибок конфигурации MS SQL Server под 1С. Планирование, дисковая подсистема, баланс памяти и процессоров, инсталляция без «далее - далее - готово», отдельная секция про виртуализацию. Написано для руководителей ИТ и администраторов, которым сервер 1С достался в нагрузку. Уровень железа общий для любой СУБД, так что владельцам ERP на Oracle и PostgreSQL тоже пригодится.
