Кратко — причин много, но почти всегда это не «магия 1С», а либо сильные случайные I/O‑операции на файле .1CD (большие чтения/записи и много мелких операций), либо внешняя конкуренция за диск (резервные копии / снапшоты / другая ВМ / SSD GC), либо особенности SSD (малый свободный объём, трим/GC, прошивка). Ниже — вероятные причины, порядок диагностики и варианты исправления.
Возможные причины
- Нагрузка от операций в самой 1С:
- формирование больших отчетов/проводок, пересчеты, обновления ссылок — приводят к интенсивным чтениям/записям;
- администр. задачи 1С (авто‑архивация/оптимизация, регламентные задания, обмен данными, фоновые обработки).
- Файловый режим 1С (один большой .1CD) даёт много случайных I/O, особенно при одновременных обращениях — чувствителен к латентности и IOPS.
- Хостовая конкуренция за диск:
- снапшоты/консолидация/репликация VM (Veeam/Backup Exec/Host backups) — частая причина пиков на VM;
- другие виртуальные машины или процессы на хосте активно используют тот же SSD.
- SSD‑специфика:
- свободного места мало (из 120 ГБ свободно ~25 ГБ) — при низком OP (overprovisioning) производительность SSD может резко падать и/или пиковая очистка (GC) вызывает задержки;
- устаревшая прошивка SSD, износ (wear leveling) — снижение производительности;
- TRIM/GC не срабатывают корректно в виртуальной среде.
- Резервные копии/индексация/антивирус/сканирование (в т.ч. со стороны хоста) — вы говорите, что отключали индексирование и антивирус на госте, но возможно на хосте или со стороны системы бэкапов процессы есть.
- Файловая система/фрагментация/права — редкий, но возможный фактор.
- Пагинация/недостаток ОЗУ → свопинг → интенсивные записи на диск.
Что проверить/как диагностировать (порядок)
1. Зафиксировать момент pика
- Запланируйте наблюдение или дождитесь очередного пика. Во время пика собирайте метрики.
2. На гостевой Windows (VM)
- Resource Monitor (resmon) → вкладка Disk: увидеть процессы с высокой активностью ввода‑вывода и файлы/пути, к которым обращаются.
- Performance Monitor (perfmon) — полезные счётчики:
- PhysicalDisk: % Disk Time, Avg. Disk sec/Read, Avg. Disk sec/Write, Current Disk Queue Length, Disk Reads/sec, Disk Writes/sec.
- Process: IO Data Bytes/sec, IO Read Bytes/sec, IO Write Bytes/sec для процессов 1cv8.exe, apache/httpd, explorer и т. п.
- Sysinternals Process Explorer / Process Monitor (procmon) — просмотреть какие файлы открываются и какими операциями (фильтровать по папке базы и по процессу 1C).
- Проверить наличие и имя процесса, генерирующего I/O (1cv8.exe, backup agent, Veeam, etc.).
3. На хосте виртуализации / сторидже
- Посмотреть общий I/O на физическом SSD: iostat/esxtop/Hyper‑V performance counters — посмотреть, нет ли других ВМ/процессов с пиками.
- Проверить, нет ли активных снапшотов/консолидаций/репликаций в моменты пиков.
- Проверить логи бэкапа (Veeam/другие), планировщики, задания репликации.
4. Диагностика SSD
- Проверить SMART, уровень износа, прошивку.
- Оценить свободное место и overprovisioning; на SSD желательно оставить ~20–25% свободными для стабильно высокой производительности.
- Узнать модель SSD и рекомендации производителя.
5. 1С‑специфика
- Проверить регламентные задания 1С (авто‑архивация, обмены, отчёты по расписанию) — может выполняться регулярно.
- Просмотреть журнал регистрации 1С — какие операции выполнялись в моменты пиков.
- Если возможно — использовать профайлер 1С (встроенные средства) для определения «тяжёлых» операций/отчётов.
6. Проверить бэкапы
- Есть ли автоматические копии базы (включая решения на хосте), снимки тома, скрипты копирования файлов базы в другое место.
Какие выводы можно ожидать
- Если Resource Monitor показывает, что нагрузку делает 1cv8.exe/процесс 1С — значит пиковая активность исходит от операций в базе (отчёты/регламентные задания). Тогда оптимизировать отчёты, расписание задач, перевести на СУБД‑сервер (client‑server).
- Если нагрузку делают процессы бэкапа/репликации/консолидации снапшотов на хосте — устранять на уровне VM/хоста (перенести бэкап в другое окно/диск).
- Если нагрузку показывает контроллер/другие ВМ — проблема хостового сториджа.
- Если диск загружается без явного чужого процесса и с высокими Avg. Disk sec/Write — вероятно SSD испытывает GC/износ или переполнение.
Рекомендации по устранению
Краткосрочные:
- При пиках поймать процесс и файл — через Resource Monitor/Procmon — и перераспределить/остановить «виновника» (если это бэкап/реплика).
- Проверить и исключить папку базы из проверки антивируса и из индексирования (как на госте, так и на хосте/антивирусе хоста).
- Отключить/пересмотреть регламентные задания и перенести тяжелые операции (бэкап, отчет, оптимизацию) на ночное время.
- Увеличить свободное место на SSD (удалить ненужные файлы, переместить другие базы на другой диск) — для SSD это часто даёт моментальное улучшение.
Среднесрочные / архитектурные:
- Перенести базу из файлового варианта в клиент‑сервер (на СУБД: PostgreSQL или MS SQL). Для 14 ГБ и растущих баз это гораздо надёжнее и масштабируемее.
- Перенести файл базы на более быстрый диск с хорошими IOPS (NVMe, выделённый RAID с кэшем) или на отдельный LUN без конкуренции.
- Обеспечить на хосте отсутствие снапшотов во время рабочего дня; настроить бэкапы так, чтобы не блокировали диск.
- При необходимости увеличить overprovisioning SSD или сменить на более качественный корпоративный SSD; обновить прошивку.
- Для виртуальной среды: использовать паравиртуальные контроллеры, оптимизировать драйвера, убедиться в оптимальной конфигурации дискового пула.
Заключение / план действий (пошагово)
1. В момент следующего пика запустите Resource Monitor → выясните процесс и файл(ы), вызывающие I/O.
2. Если это 1С → посмотрите журнал регистрации 1С и профайлер: какие операции выполнялись в этот период.
3. Если это процесс бэкапа/репликации/хоста → на хосте проверьте снапшоты и задания бэкапа (и перенесите/перепланируйте их).
4. Соберите perfmon (несколько часов) и iostat/esxtop на хосте — для понимания, где именно узкое место.
5. Увеличьте свободное место на SSD и проверьте прошивку/ SMART.
6. По результатам диагностики примите одно из масштабных решений: перенести базу на выделенный диск/сервер СУБД.
Если хотите, могу:
- дать точный список perfmon‑счётчиков и шаблон для съёма данных;
- прислать пошаговую инструкцию по использованию Procmon для фильтрации по папке базы;
- помочь интерпретировать собранные логи/метрики, если вы пришлёте результаты.
Скажите, на каком гипервизоре/хосте размещён VM (ESXi/Hyper‑V/vCenter/Proxmox), и сможете ли вы в момент пика собрать Resource Monitor или perfmon — и я подготовлю точные команды/фильтры.