Показательный пример.
База использовалась около месяца. Всё это время с ней активно работали.

Как заметно из рисунка, файловая система NTFS замечательна.
Оптимизация данных MS SQL превосходна.
Дефрагментацию надо ставить в планировщик, хотя бы на раз в месяц.

Напоминаю, что операция дефрагментирования не очень полезна в плане износа жёсткого диска и потенциально опасна для самой системы.
С другой стороны, при таком состоянии данных скорость работы базы сильно замедляется.

Как делать дефрагментацию?

Файл базы данных используется MS SQL, который, в свою очередь, получает команды от сервера 1С. Чтобы сделать файл доступным для дефрагментации и избежать сбоев, нужно правильно погасить связанные службы.

Порядок операций:

1. Останавливаем службу сервера 1С
2. Останавливаем службу сервера MS SQL
3. Делаем дефрагментацию раздела
4. Запускаем службу сервера MS SQL
5. Запускаем службу сервера 1С

Желательно сделать скрипт и поставить в планировщик на время, когда база точно не будет использоваться — например, ночь выходного дня.
Промежуток для планировщика проще всего выбирать опытным путём.

Можно ли поставить базу на SSD-диск?

Нет, ни в коем случае.

SSD очень шустрые. И доступ к данным внутри SSD-дисков устроен так, что понятие "фрагментации" практически отсутствует. То, что данные будут идти не "по порядку" — никак не скажется на скорости.

Вот только технология SSD всё ещё остаётся ненадёжной, и диски летят очень быстро даже при умеренной нагрузке. Что будет происходить с ними при полной нагрузке — догадаться совсем несложно.

Для достижения оптимального баланса между производительностью и надёжностью надо использовать RAID 5 на обычных дисках.

Нужно ли делать дефрагментацию, если база находится на рейде?

Да, обязательно.

В RAID данные бьются на блоки размером chunk_size (по умолчанию 64КБ), которые перераспределяются по элементам рейда.
Файловая система создаётся на массиве, то есть — внутри этой структуры. (Именно поэтому для производительности рекомендуют делать размер кластера ФС равным chunk_size и выравнивать её относительно рейда).

Если файл цельный, то его рейдовые блоки находятся рядом на каждом из физических дисков — а значит, и прочитаются быстрее. И наоборот, если файл фрагментирован, то его надо будет собирать по кускам на всех физических носителях.

То есть, рейдовое перераспределение данных по нескольким дискам никак не отменяет издержек из-за фрагментации на файловой системе.



demiurg
2010.02.15 14:40:01
#cid154

Ответить

"здрасьте, я ваша тетя"...

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

и о чудо, не все так и хреново :)

2010.02.16 04:23:55
#cid155

Ответить

Здравствуй, Вячеслав :)

Этот сервак не я ставил и не я настраивал. Там криво всё, вплоть до разбивки диска и выбора мест для хранения данных. Компания небольшая, админил «одмин», серверные роли на машинах совмещены неудачно.
Дело даже не в этом. Увидел, повеселило, решил поделиться с массами - как оно бывает. Это ж не полноценная техническая статья.

Если копать, то дефрагментацию системного раздела надо делать сразу после установки системы и драйверов. Потому что свежеустановленные XP и 2003, как бы странным это ни казалось, уже фрагментированы по самое небалуй.
После настройки и дефрагментации системы - снять образ, для себя или для будущих поколений.
Хранить рабочую базу - не на системном разделе.
И т.д., и т.п. Но - в другой раз и в другой статье, если дойдут руки написать.

Резервирование максимального места - известная попытка борьбы с фрагментацией NTFS.

> и о чудо, не все так и хреново :)

Согласен. Всё равно хреново, но действительно не настолько :)

И эта, дефрагментацию на подобных серверах всё-таки надо ставить в планировщик.

2014.12.12 18:38:53
#cid90009

Ответить

Так как на эту заметку стали ссылаться как на техническую, пришлось изменить её формат и добавить информации.

Чтобы соответствовать.