Почему сервер 1С через 2 года тормозит: разбираем деградацию SSD в офисных серверах

Привет! Я, Семёнов Евгений Сергеевич, уже 15 лет занимаюсь IT-инфраструктурой для средних офисов в Москве и Подмосковье. Знаете, какой вопрос я слышу от новых клиентов чаще всего? Примерно такой: «Наш сервер 1С пашет уже два года, раньше всё просто летало, а теперь бухгалтерия готова нас порвать — отчёт формируется по 8 минут, а документ открывается 15 секунд». Вот в этой статье я и хочу разобрать, почему так происходит на самом деле, и рассказать о нашем проверенном алгоритме, как мы это диагностируем и лечим.

Симптомы, которые рассказывают историю

Когда клиент описывает проблему по телефону, я уже примерно знаю, что увижу на месте. Картина классическая:

• Сервер собран 18–28 месяцев назад как «среднебюджетная сборка для 1С».
• В системнике стоят два-четыре потребительских SSD Samsung 870 EVO или Samsung 980 Pro.
• Объединены в RAID 1 или RAID 5/10 на встроенном контроллере материнки или на дешёвом аппаратном RAID-контроллере.
• Заполнение тома 75–95%.
• Первые 8–14 месяцев всё работало хорошо, потом постепенно стало хуже, последние 2–3 месяца — невыносимо.

В девяти случаях из десяти, я вам скажу, причина кроется в деградации SSD. И это не какая-то там аппаратная поломка, не то, что «диски умерли», нет. Это именно особенности физики NAND-памяти, которые, увы, не учли, когда проектировали сервер. Сейчас объясню поподробнее, почему так происходит.

Откуда берётся деградация: коротко про физику NAND

SSD пишет данные не побайтово, как HDD, а блоками по 4–16 МБ (page erase block). Чтобы перезаписать один байт, контроллеру SSD приходится прочитать весь блок, изменить нужный байт в кэше, стереть блок целиком и записать его обратно. Это и есть write amplification — реального объёма записи больше, чем попросил хост.

Чтобы вся эта махинация работала шустро, SSD всегда держит такой специальный «карман» — запас свободных, заранее подготовленных блоков. Но вот беда: когда диск заполняется до 80–85%, этого «кармана» уже не хватает. Что делает контроллер? Начинает натурально «жонглировать»: под каждую новую запись ему приходится сначала освобождать место. И что мы получаем в итоге? Запись замедляется в 5–20 раз, а задержки вырастают с каких-то там миллисекунд до ощутимых 50–100 мс.

Вот для чего нужна команда TRIM! Она словно даёт операционной системе возможность сказать SSD: «Эй, вот эти блоки теперь свободны, можешь их заранее подготовить». Если же TRIM не работает (а в наших офисных серверах с каким-нибудь дешёвым RAID-контроллером это, увы, частая история), то этот самый «карман» просто не пополняется. В итоге SSD начинает умирать, что называется, «по жизни», а не из-за того, что его ресурс записи исчерпан.

Почему потребительские SSD в сервер 1С — это бомба замедленного действия

На самом деле, разница между потребительским и серверным SSD вовсе не в скорости – в синтетических тестах они часто показывают похожие результаты. И даже не в объёме. Всё дело вот в чём, есть три ключевых отличия:

Когда вам системный интегратор предлагает сервер, скажем, за 280 000 руб., самый простой и, к сожалению, распространённый способ его удешевить — это воткнуть четыре потребительских SSD вместо двух серверных. Заказчик, конечно, в восторге: «У меня же целых 8 терабайт!» Но вот проходит два года, и этот же самый заказчик уже проклинает интегратора и, что логично, звонит нам.

Вот вам пример из нашей практики, буквально из 2024–2025 годов: у одного клиента, производителя из Балашихи, на сервере 1С стояли четыре диска Samsung 870 EVO 4 ТБ, собранные в RAID 10. Прошло всего 22 месяца, и что мы видим в показателях smartctl? Wear Leveling Count — 8% (это значит, что от заявленного ресурса осталось всего 8%), а Total Bytes Written — 980 ТБ из обещанных 2400. Сервер при этом тормозил так, что бухгалтерия просто физически не успевала закрывать месяц. Мы решили проблему, заменив их на пару Samsung PM9A3 1.92 ТБ в зеркале. Итог? Отчёт, который раньше формировался 11 минут, теперь готов за 45 секунд. Разница, как говорится, налицо.

Аппаратный RAID-контроллер: ещё один ингредиент катастрофы

Есть такая старая привычка, которая тянется ещё с эпохи HDD: «нормальный сервер просто обязан иметь нормальный RAID-контроллер». И, честно говоря, для жёстких дисков это действительно работало: контроллер с батарейкой заметно ускорял работу и надёжно защищал данные, если вдруг отключалось питание. Но вот для SSD это, к сожалению, почти всегда приносит только вред.

В чём проблема? Большая часть аппаратных RAID-контроллеров, выпущенных до 2022 года, просто не умеет передавать команду TRIM на SSD. Контроллер воспринимает весь том как одно огромное блочное устройство и понятия не имеет, что там внутри — SSD. В итоге, наш SSD не получает нужной информации о свободных блоках, тот самый «карман» не пополняется, и уже через 6–12 месяцев производительность может упасть в разы.

Что мы делаем в АйТи Фреш с 2022 года:

• На Linux-серверах — программный RAID через mdadm. TRIM работает по умолчанию, скорость не уступает аппаратному, цена — ноль.
• На Windows-серверах — Storage Spaces. Тоже бесплатно, тоже с TRIM.
• Если клиент настаивает на аппаратном RAID — только Broadcom 9560-серии или новые HPE Smart Array P408i-c с явной поддержкой SSD и TRIM. Прошивку обновляем до последней.
• Контроллеры HPE P420/P440 и LSI 9271 — выкидываем и меняем на HBA в IT-mode.

Как мы диагностируем: типовая процедура

Когда клиент жалуется на тормоза сервера, я выезжаю с ноутбуком и набором инструментов. Алгоритм такой:

1. Проверка SMART каждого диска. Команда smartctl -A /dev/sda на Linux или CrystalDiskInfo на Windows. Смотрим Wear Leveling Count, Total Bytes Written, Reallocated Sectors. Если ресурс вышел — диагноз готов.
2. Проверка TRIM. На Linux: lsblk -D — если DISC-MAX равен 0B, TRIM не работает. На Windows: fsutil behavior query DisableDeleteNotify. Если 1 — TRIM выключен.
3. Проверка заполнения. Если заполнение тома больше 80%, добавляем это в список причин.
4. Проверка очереди I/O. На Linux iostat -xz 1, на Windows — Performance Monitor с счётчиком Avg. Disk Queue Length. Если очередь регулярно больше 4 — диски не справляются.
5. Бенчмарк на текущей нагрузке. Запускаю fio с типичным паттерном 1С (random read/write 4k), сравниваю с эталоном для конкретной модели SSD.
6. Проверка типа дисков. По модели понимаю, потребительские или серверные.

По результатам проверки я всегда выдаю подробный отчёт, где предлагаю три возможных сценария решения проблемы: первый — это «лечение без замены дисков» (здесь мы делаем Secure Erase и переразметку с over-provisioning); второй — «частичная замена» (меняем только самый изношенный диск на серверный); и, наконец, третий — «полная пересборка» (это означает новые серверные SSD и полноценную миграцию данных).

Что мы рекомендуем при сборке нового сервера 1С

Для офиса на 15–40 пользователей 1С наша типовая конфигурация в 2026 году:

Что касается затрат? На само железо уходит примерно 700–900 тыс. руб. — тут всё зависит от того, сколько у вас пользователей. Сборка, настройка, плюс миграция базы 1С — это ещё 90–140 тыс. руб. В общем, если брать «под ключ», получается около миллиона. Зато потом всё это прослужит вам 5–7 лет, и без какой-либо заметной деградации.

Лечение «уже больного» сервера: реальный кейс

А вот реальный кейс, Март 2026 года. Производственная компания, район Кунцево, у них 24 пользователя 1С УПП. Сервер, кстати, был собран в 2023 году ещё их бывшим админом: там стояли четыре Crucial MX500 2 ТБ в RAID 5, организованном на встроенном RAID Intel RST. Главные жалобы? Закрытие месяца стало занимать целых 4 часа, хотя раньше укладывались в обычные 40 минут.

Диагностика заняла у меня всего два часа. Картина вырисовывалась такая: Wear Leveling Count на дисках колебался от 14% до 22%, том был заполнен на 88%, а TRIM через Intel RST, как и ожидалось, не работал (это, кстати, давно известная проблема 17-й серии RST). Очередь I/O в пиках доходила до 18–24. Мой диагноз был однозначен: это такое «комбо» — выработанный ресурс, отсутствие TRIM и переполнение дискового пространства.

План работ:

1. Холодный бэкап базы 1С на внешний диск (3 часа).
2. Замена четырёх Crucial MX500 на два Samsung PM9A3 1.92 ТБ + два Samsung PM9A3 3.84 ТБ.
3. Перенос RAID-конфигурации на программный mdadm под Debian (систему пришлось переустанавливать).
4. Включение TRIM через fstrim.timer раз в сутки.
5. Восстановление базы 1С, проверка целостности, тестовый запуск ключевых отчётов.

Всю работу мы выполнили оперативно — начали вечером в пятницу в 18:00 и закончили к субботе 14:00. Что по деньгам? Стоимость наших работ составила 65 тыс. руб., а новые диски обошлись в 218 тыс. руб. Зато уже с понедельника закрытие месяца снова стало занимать всего 38 минут.

Что показывает SMART: расшифровка на пальцах

Чтобы любой клиент мог самостоятельно разобраться, в каком состоянии находится его SSD, я всегда объясняю значение ключевых атрибутов SMART. Особенно важно обратить внимание на три критичных:

• Wear Leveling Count (177 / 173 в зависимости от вендора). Это процент остаточного ресурса. 100% — диск как новый, 0% — выработал весь заявленный TBW. После 30% диск ещё работает, но я планирую замену в течение полугода. После 10% — это бомба, которая взорвётся в любой момент.
• Total LBAs Written (241). Сколько данных было записано за всю жизнь диска. Делите на 2 048 000, чтобы получить терабайты. Сравниваете с заявленным TBW — это и есть выработка ресурса в абсолютных цифрах.
• Reallocated Sectors Count (5). Количество переназначенных секторов. У SSD это редкое явление, любое значение больше нуля — повод присмотреться. Растёт со временем — диск явно умирает.

В рамках нашей абонентской поддержки мы настроили автоматический сбор этих показателей через Zabbix-агент со всех клиентских серверов, причём делаем это раз в сутки. И, конечно, ставим алерт на любое превышение порогов. Благодаря этому диски меняются планово — ещё ДО того, как они успеют стать реальной проблемой. А не так, как это часто бывает, аварийно ночью под панические крики «всё пропало!»

Чек-лист профилактики для уже работающего сервера

• Минимум раз в квартал смотреть smartctl/CrystalDiskInfo и записывать показатели в журнал.
• Контролировать Wear Leveling — при выработке более 60% планировать замену.
• Не допускать заполнение тома выше 75%.
• Убедиться, что TRIM работает (на Linux fstrim.timer, на Windows — Optimize Drives).
• Раз в год обновлять прошивку SSD и RAID-контроллера.
• Мониторить задержки I/O через Zabbix/PRTG, ставить алерт на превышение 20 мс.
• Иметь два запасных диска той же модели, чтобы при выходе из строя не ждать поставки.

Что делать прямо сейчас, не дожидаясь катастрофы

Что ж, если вы дочитали до этого момента и понимаете, что все описанные симптомы — это прямо про вашу ситуацию, то вот вам мой короткий, но очень важный план действий на ближайшую неделю:

1. Сегодня вечером. Скачать CrystalDiskInfo (для Windows) или собрать вывод smartctl -a с каждого SSD на сервере. Записать показатели Wear Leveling Count и Total LBAs Written в табличку с датой.
2. Завтра утром. Проверить, какой процент тома заполнен. Если больше 80% — срочно почистить или расширить.
3. На неделе. Найти модели всех SSD в сервере, погуглить «модель + datasheet TBW», сравнить с вашим Total Bytes Written. Понять, на каком вы проценте выработки.
4. В этом месяце. Если выработка больше 60% или диски потребительские — заказать диагностику у профильного подрядчика и спланировать замену до того, как начнутся реальные проблемы.
5. Раз в квартал постоянно. Снимать показатели SMART и сравнивать с прошлым квартом. Если рост Total Bytes Written ускоряется — что-то изменилось в нагрузке, надо разбираться.

И самое важное: пожалуйста, не ждите, пока ваша бухгалтерия начнёт жаловаться на тормоза. Поймите, к тому моменту, когда эти зависания становятся заметны обычному пользователю, SSD уже находится глубоко в зоне деградации, и времени на спокойную, плановую замену почти не остаётся.

FAQ — частые вопросы

Почему мой сервер 1С через 2 года стал тормозить?

В 70% случаев — это деградация потребительских SSD: либо кончился ресурс TBW, либо TRIM не работает через RAID-контроллер, либо заполнение выше 80%.

Какие SSD ставить в сервер 1С на 25 пользователей?

Только серверные: Samsung PM9A3, Intel D7-P5520, Micron 7450 Pro. Потребительские Samsung 980/990 Pro в сервер ставить нельзя.

Лучше брать аппаратный RAID или собирать на mdadm?

Для SSD — программный mdadm на Linux или Storage Spaces на Windows. Аппаратный RAID часто блокирует TRIM, что убивает производительность.

Сколько живут серверные SSD в реальной офисной нагрузке?

Серверные SSD класса 1 DWPD на сервере 1С под 30 пользователей живут 5–7 лет. Потребительские — 14–24 месяца.

Что делать, если сервер уже тормозит — менять диски?

Сначала диагностика. В половине случаев помогает Secure Erase + переразметка с over-provisioning 25% и включение TRIM. Если ресурс выработан более 90% — только замена.