gifts2017

Как правильно настроить MS SQL сервер для работы с 1С

Опубликовал Алексей Новоселов (a-novoselov) в раздел Администрирование - Оптимизация БД (HighLoad)

Путем проб и ошибок, путем тестирования на 200+ живых пользователей, консультаций с десятками Гуру и поиска по сотням официальных и не очень сайтов был разработан оптимальный вариант настроек MS SQL для круглосуточной работы более, чем 200 пользователей одновременно.

 1. Настройка сервера

Во-первых нам нужен только сервер, остальные службы, которые к нему относятся и возможно кто-то ими пользуется, нам только тормозят работу. Останавливаем и отключаем такие службы, как FullText Search (у 1С собственный механизм полнотекстового поиска), Integration Services и иже с ними.

Оставляем только:

SQL Server (sqlservr.exe)

SQL Server Agent (SQLAGENT.exe)

SQL  Writer (sqlwriter.exe)

Далее в свойствах сервера, через Server Management Studio устанавливаем:

 

Максимально отведенное серверу количество памяти из расчета:

[Общее количество оперативной памяти сервера] – [4ГБ под систему(2ГБ если Win2003)] – [1,5 ГБ * количество процессов rphost (если SQL и 1С на одном сервере вращаются.)] Например если у нас на сервере всего 36 ГБ оперативной памяти, стоит Windows 2008 и запущено 8 процессов rphost то рассчет идет так: 36 - 4 - 1.5*8 = 20 ГБ ставим ограничение для SQL.

Это необходимо для того, чтобы sql сервер рассчитывал на этот объем и чистил память заблаговременно, т.к. если поставить неограниченный объем, и сервер попробует получить память, которой нет, он начинает крепко задумываться над своим поведением и крайне медленно отвечать на запросы.

Далее:

 

Максимальное количество потоков (Maximum worker threads) ставим 2048, по умолчанию стоит 0 и с таким значением сервер не создает больше 255 потоков, а этого ему не хватает (установлено опытным путем, что при большом количестве одновременных транзакций сервер реально начинает быстрее работать). Также выставляем галку повышенного приоритета сервера (Boost priority).

Собственно с глобальными настройками все. Теперь переходим к настройкам рабочей базы данных (или нескольких баз, если такое имеет место быть).

2. Настройка рабочей базы данных

Заходим в свойства нужной нам базы данных:

 

Если база еще не развернута из .dt файла, и вы знаете примерный ее размер, то первичному файлу размер инициализации лучше сразу указать >= размера базы, но это дело вкуса, он все равно вырастет при развертке. А вот Автоувеличение размера надо обязательно указать примерно по 200 МБ на базу и по 50 МБ на лог, т.к. значения по умолчанию – рост по 1МБ и по 10% очень сильно тормозят работу сервера, когда ему при каждой 3й транзакции надо файл увеличивать. Также, если не используетет RAID массив, то хранение файла базы и файла лога лучше указать на разных физических дисках. Ну и ограничить лог 2-4 ГБ, чтоб сильно не пух.

Остальные настройки как на скришоте:

 

С настройками базы все. Осталось настроить регламентные задания.

3. Настройка регламентных заданий

Сначала создаем Maintenance Plan в разделе Management:

 

Дефрагментацию индексов и сбор статистики нужно производить ежедневно, т.к. если фрагментированость индексов > 25%, это резко снижает производительность сервера. Дефрагментация и обновление статистики делается быстро и не требует отключения пользователей. Насколько ваши индексы фрагментированы можно посмотреть очень хорошей и многофункциональной обработкой Гилева Вячаслава, с названием Lock1C.epf, и которую он убрал со своего сайта из-за наезда 1С-ников за нарушение какого-то пункта лицензионного с., но хорошему админу гугл всегда в помощь J . Также желательно делать полную переиндексацию, с блокировкой БД, хотя бы раз в неделю, естественно после полной переиндексации сразу же делается дефрагментация индексов и обновление статистики.

Настройка бэкапа средствами SQL.

Ту все просто, добавляем 2 новых задания Agent'у:

 Full BackUp, с периодичностью 1 раз в сутки и 2мя шагами T-SQL скриптов:

1.       BACKUP DATABASE [<ИмяБД>] TO  DISK = N'<ПутьКПапке>\Backup\<ИмяБД>.bak' WITH NOFORMAT, INIT,  NAME = N'<ИмяБД>-Full Database Backup', SKIP, NOREWIND, NOUNLOAD,  STATS = 10

GO

2.       USE [<ИмяБД>]

GO

DBCC SHRINKFILE (N'<ИмяБД>_log' , 0)

GO

И второе задание с периодичностью 1 раз в 1-2 часа Differencial BackUp и с одним T-SQL скриптом:

BACKUP DATABASE [<ИмяБД>] TO  DISK = N'<ПутьКПапке>\Backup\<ИмяБД>Diff.bak' WITH  DIFFERENTIAL , NOFORMAT, INIT,  NAME = N'<ИмяБД>-Differential Database Backup', SKIP, NOREWIND, NOUNLOAD,  STATS = 10

GO

Такой бэкап делается, даже при активной работе пользователей, 4-6 минут и практически не сказывается на быстродействии сервера.

Да, и добавим очистку процедурного после переиндексации (раз в неделю), в задание, кторое у же появилось в агенте после сохранения Maintenance Plan добавляем еще один шаг:

DBCC FREEPROCCACHE

GO

Не забыв поменять в настройках первого шага после завершения не выходить, а перейти к следующему. Спс gilv за подсказку.

Вот, собственно, и все. По поводу бэкапа средствами 1С: http://infostart.ru/public/65849/ - Full BackUp и выгрузку 1С можно делать одновременно.

См. также

Подписаться Добавить вознаграждение
Комментарии
1. larissa builova (larisab) 17.02.10 20:42
2. Дмитрий Синдели (Sindelik) 17.02.10 20:52
3. Герман (German) 17.02.10 21:18
Также желательно делать полную переиндексацию, с блокировкой БД


При индексации блокируется только таблица, незачем делать ее в режиме тестирования и исправления.
4. Сергей Лунев (luns) 17.02.10 21:22
Еще бы добавил, что неплохо было бы выставить в свойствах сетевого соединения сервера для компоненты "Служба доступа к файлам и принтерам сети Microsoft" оптимизацию не для файлов а для сетевых приложений.
5. Валерий Гуров (Saint) 17.02.10 23:20
Нифига не понял в формуле расчёта максимального количества памяти.
6. Евгений Стоянов (quick) 18.02.10 08:02
Полезная статья. Но в расчет памяти я что то тоже не врублюсь
7. Александр Андрющенко (anderson) 18.02.10 09:09
С какой целью делается DBCC SHRINKFILE (N'<ИмяБД>_log' , 0), если у вас recovery model = simple?
8. Andriy Androsovych (Androsovych) 18.02.10 11:16
Время выполнения операций, заявленное в обзоре, сильно зависит от размера самой базы; переиндексация на базах больше сотни Гб может длиться дольше часа.
9. Алексей Новоселов (a-novoselov) 18.02.10 11:30
(8) Вот поэтому она и сделана на ночь с воскресения на понедельник с 01:00... Люди начнут работать все равно не раньше 08:00
10. Алексей Новоселов (a-novoselov) 18.02.10 11:34
11. Алексей Новоселов (a-novoselov) 18.02.10 11:37
(7) Были преценденты, что лог не урезался, решили добавить ручное "обрезание".
12. Александр Андрющенко (anderson) 18.02.10 12:14
(11) а зачем вообще урезание? чем меньше операций по выделению места под файлы данных/лога, тем меньше тормозов
13. Валерий Гуров (Saint) 18.02.10 12:16
А что такое "Общее количество памяти сервера"? Это размер ОЗУ? Но цифра в примере непонятная.
14. Алексей Новоселов (a-novoselov) 18.02.10 12:26
(12) Лог, без урезания, начинает сильно фрагментироваться (куча маленьких свободных/занятых кусков внутри файла), что негативно сказывается на работе.
(13) Да, это размер ОЗУ.
15. glinmn (glinmn) 18.02.10 13:11
Более грамотный подход к архивированию читаете в учебнике http://www.learn1c.ru/ebooks/book002.html
При подходе описанном автором 100% геморрой при восстановлении. и проблнмы с log'ом
А настройка сервера для новичков -хороша.

16. Валерий Гуров (Saint) 18.02.10 13:12
(14) Формула интересная, только вот по ней у меня на сервере нужно установить значение -1 ГБ (т.е. отрицательное значение). :cry:
17. Алексей Новоселов (a-novoselov) 18.02.10 13:39
(15) Во-первых ваша ссылка для 7ки (кстати тоже неоднократно посещалась при поиске информации), во вторых никакого геморроя с восстановлением - раз в 2 дня в тестовую базу восстанавливаем: 20 минут из полного файла, 15 минут из diff файла и готовая база примерно на час отстающая от рабочей. А вот при полной модели бэкапа (full а не simple), какраз имеете огромный геморой с восстановлением, т.к. если лог натянете на полный бэкап, то diff не встанет, если diff натянете, то лог не встанет... целостность базы нарушена полюбому. А в simple-модели бэкап лога не нужен.

(16) Если у вас rphost'ы максимум по 500 МБ отъедают памяти в процессе работы, то столько им и оставляйте. Сдесь взято по максимуму и у нас они действительно по столько иной раз занимают (правда не видал, когда все одновременно, но чем чорт не шутит...)
18. Андрей М (_Z1) 18.02.10 13:50
Помимо размера и log рабочей базы
необходимо также настраивать размер и log базы tempdb
Размер этой базы должен составлять от 25% до 40% самой большой базы данных
Лучший вариант размещения базы данных tempdb – на отдельном диске или дисковом массиве RAID0 (эта база данных не нуждается в восстановлении).
Приращение лога для temdb - обязательно не в процентах.

19. Андрей М (_Z1) 18.02.10 14:06
Про Максимальное количество потоков ставим 4096 ИХМО вы что-то перемудрили.
Ставя явно 4096 Вы резервируете для sql сервера пул рабочих процессов.
Если общее количество подключений к серверу меньше этого числа то каждому подключению выделяется свой рабочий поток иначе для коннекта назначается поток из пула.
Т.е если к примеру у Вас общее число подключений к серверу меньше 2000 то 4096
ставить неправильно так как каждый рабочий поток резервирует память ( об этом косвенно говорит и тот факт что для изменения параметра нужна перестартовать sql сервер).
Как действует значение 0 точно не скажу это надо отдельно разбираться взависимости от
(select @@version) версии sql (2000,2005,2008)
20. Алексей Новоселов (a-novoselov) 18.02.10 14:07
(18) Насчет размещени tempdb вы абсолютно правы, а вот насчет размера - это довольно спорный вопрос... одно время, еще на старом сервере с небольшим объемом оперативы когда работали, у нас для базы в 6 ГБ tempdb разростался до 30 ГБ, и когда мы решили ограничить размер tempdb до 6 ГБ, то при достижении указанного размера сервер просто вставал, спасал только полный ребут. а без ограничения кое-как работал, правда тормозил неподетски. Вообще конечно продукты MS очень требовательны к ресурсам и очень часто первоопределяющий фактор - быстродействие сервера и наличие рэйда.
21. Алексей Новоселов (a-novoselov) 18.02.10 14:16
(19) Возможно число можно указать и поменьше, но памяти процессы резервируют по минимуму и не факт, что стартуют при отсутствии подключений, а вот когда 2 подключения на один поток садятся, то у людей начинаются ториоза, ИМХО число лучше сразу задать как можно больше. Темболее ожидается увеличение количества пользователей до 400-500 человек, и каждый ведь может по несколько раз 1С запустить... + регламентные задания, роботы всякие и т.п.
22. Андрей М (_Z1) 18.02.10 14:22
(20) насчет размера согласен.
Просто эта цифра 25-40% это как общая рекомендация.
Точное значение надо подбирать индивидуально для каждого сервера.
Если есть какая нибудь методика то с удовольствием с ней познакомился бы.
Тут как всегда компромис чем больше размер тем лучше. Но дисковое пространство сервера как правило очень дорогой ресурс и его надо как-то ограничивать.
Как выставлять приращение log для tempdb точно не знаю но желательно чтобы sql
делал это редко.
23. sound sound (sound) 18.02.10 14:43
24. Андрей М (_Z1) 18.02.10 14:43
(21) Если пользователь запустил несколько сессий то не факт что он в них одновременно работает. Т.е если у Вас 95% времени выполняется 2000 активных соеденений ( которые что-то считают ) то и выставлять надо 2000. Выставляя 4096 Вы отбираете у sql сервера память и он не сможет её(память) использовать под свои задачи.
Я исхожу из своих знаний на основе sql200,sql2005 Как резервируется память
под это дело в sql2008 я точно не знаю ( думаю что также)
Также надо учитывать и возможности сервера.Предположим что конкретный сервер не может одновременно обслуживать более 3000 потоков. В таком случае ставить 4096 тоже бессмысленно.
Про значение 0
В sql2000 это равно 255 рабочим потокам
В sql2005 ( и наверное sql2008 ) 0 означает что sql сервер сам по внутреним алгоритмам динамически меняет количество рабочих процессов. Для каких то нагрузок это может и хорошо для каких-то не очень хорошо.
При любых других (не 0 ) значениях я считаю что память под рабочие процессы выделяется статически при старте sql сервера.
a-novoselov; +1 Ответить 2
25. Алексей Новоселов (a-novoselov) 18.02.10 15:08
(24) Кстати SQL умеет распараллеливать запросы, т.е. 1 большой запрос может идти в несколько потоков.
26. Андрей М (_Z1) 18.02.10 15:18
(25) это тоже надо настраивать отдельным параметром
и как правило не рекомендуют ставить значение больше 5.
Фишка в том что при большом распаралеливании sql начинает слишком много времени тратить на само планирование и разбиение запроса вместо его выполнения
и общая производительность падает вместо ожидаемого роста.
27. Алексей Новоселов (a-novoselov) 18.02.10 15:25
(26) Да, мы тоже сперва MaxParallelism в 5 выставили, но с 0 на замерах производительности большие запросы быстрее обрабатывались...
28. glinmn (glinmn) 18.02.10 16:49
Хи-ха, Я работаю с базами от 40 -120Gb и я посмотрел бы с удовольствием на Ваши действия при падении Log файла или файла базы. Все это очень хорошо при небольших базах , но они имеют дурную привычку быстро расти и при этом начинаются другие проблемы
u_n_k_n_o_w_n; maxbd; McSim; Reaper_1C; +4 Ответить 1
29. Dimka74 Dimka174 (Dimka74) 18.02.10 20:45
Все здорово, осталось только видео сделать и на Ютруб выложить. ;)
30. gilv (Gilev.Vyacheslav) 18.02.10 21:49
Boost priority - что дает?
Сервер 1С находится вместе с сиквелом?
почему минимум = 0?

наверно слишком пафосно "правильная настройка", скорее "настройка для случая Х"
еще многе зависит от операционки, разрядности и т.п.

вцелом труд в правильном направлении сделан, хотя некоторые выводы необоснованы
gv.pretorian; WildFire; IgorTsapko; bashta.aleksey; +4 Ответить 1
31. Алексей Новоселов (a-novoselov) 19.02.10 06:48
(30) Boost priority - увеличивает приоритет сервера.
Да, сейчас 1С и SQL вместе находятся. До недавнего времени на разных машинах висели, но настройки оптимальные были такими-же...При переносе SQL на сервер, где 1С вращается, производительность чуть-чуть возросла, хотя сервера были по мегабитному каналу связаны.
Насчет разрядности вы правы, на 32х все равно больше 4 ГБ оперативы не увидит операционка, и тут уже смысла нет память ограничивать, или 3-3,5 ГБ ограничение ставить, т.к. ее итак нет.
32. Алексей Новоселов (a-novoselov) 19.02.10 06:50
(28) Может поделитесь какие проблемы могут возникнуть?
Файл базы у нас падал, и мы его никак не смогли восстановить. Пришлось поднимать базу из бэкапа, перед этим скопировав базу с логом на тестовый сервер... Для аттача этой базы никакие шаманские действия не помогли. Скачал утилиту от MS, которая, типа, битые базы поднимает, она за неделю 50% файла обработала, при том на каждой второй операции сообщала об ошибке... Остановил процесс за ненадобностью.
33. Александр Крынецкий (echo77) 19.02.10 09:06
(31)
Насчет разрядности вы правы, на 32х все равно больше 4 ГБ оперативы не увидит операционка, и тут уже смысла нет память ограничивать, или 3-3,5 ГБ ограничение ставить, т.к. ее итак нет.

- в этом вы не правы. Серверная x32 ОС видит больше 4 Гб памяти, для того чтобы SQL-сервер мог адресоваться к памяти выше 4 Гб необходимо включить AWE (см. скриншот 1)
ojiojiowka; jan27; +2 Ответить 1
34. Алексей Новоселов (a-novoselov) 19.02.10 09:26
(33) Там страницы по 4 ГБ получаются и обращение к памяти медленно работает. Смысла нет 32х разрядную ось ставить на сервер, где больше 4 ГБ памяти.
35. Александр Крынецкий (echo77) 19.02.10 09:53
(34) никто не спорит, но и писать что операционка больше 4Гб не видит - тоже не стоит
36. gilv (Gilev.Vyacheslav) 19.02.10 10:34
(31)
Boost priority - увеличивает приоритет сервера.

Ну увеличивает. А как это сказывается (в цифрах и фактах пожалуйста).
Да, сейчас 1С и SQL вместе находятся. До недавнего времени на разных машинах висели, но настройки оптимальные были такими-же...

На счет настройки памяти не соглашуюсь. На отдельно стоящем сиквеле и совмещенном настройки памяти разные.
Опять таки, зачем на отдельно стоящем скуле вообще приоритет повышать.

При переносе SQL на сервер, где 1С вращается, производительность чуть-чуть возросла, хотя сервера были по мегабитному каналу связаны.

Сколько сетевух на сервере? Может быть пора посмотреть 10гигабитку.
К тому же не всегда есть возможность и целесообразность совмещать.
А то Вас тут почитают и таких дров наломают.

Но это так, непринципиальная критика. Просто не хотелось бы рядом с дельными советами видеть "отсебятину". Т.е. лучше меньше советов, но максимально дающих эффект.
zinal; ojiojiowka; jan27; vbazaroff; a-novoselov; +5 Ответить
37. glinmn (glinmn) 20.02.10 12:48
Не хорошо писать письма без обратного адреса.
а по делу- по комментируйте(дело было в понедельник 15 февраля), что и как вы по Вашей схеме будете восстанавливать:
ЗАГОЛОВОК: Microsoft SQL Server Management Studio
------------------------------

Не удается вывести требуемое диалоговое окно.

------------------------------
ДОПОЛНИТЕЛЬНЫЕ СВЕДЕНИЯ:

Не удается вывести требуемое диалоговое окно. (SqlMgmt)

------------------------------

SQL Server обнаружил логическую ошибку ввода-вывода, связанную с согласованностью: неверный идентификатор страницы (ожидаемый 1:712; фактический 0:0). Она произошла при прочитать страницы (1:712) в базе данных с идентификатором 4 по смещению 0x00000000590000 файла "C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MSDBData.mdf". Дополнительные сведения см. в журнале ошибок SQL Server и журнале системных событий. Это серьезная ошибка, которая угрожает целостности базы данных и должна быть немедленно исправлена. Выполните полную проверку базы данных на согласованность (DBCC CHECKDB). Эта ошибка может быть вызвана многими причинами; дополнительные сведения см. в электронной документации по SQL Server. (Microsoft SQL Server, ошибка: 824)

Чтобы получить справку, щелкните: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&EvtSrc=MSSQLServer&EvtID=824&L­inkId=20476

------------------------------
КНОПКИ:

ОК

38. glinmn (glinmn) 20.02.10 13:06
В дополнение предыдущему:
- работающий магазин, остановка очень догая и начальство за спиной стоит
- Win 2003/32, sql 2005/32, 1c 8.1, база ~100Gb
- техника обычная для нашего бизнеса.

39. Алексей Новоселов (a-novoselov) 24.02.10 11:35
(37) (38) Дак по-английски ведь написано, что железо сбоит. У нас одно время сервак тупо ребутался, как будьто кто-то резет жмет 2-3 раза в день, в логах винды писал только что "завершение работы было неожиданным..." спас только переезд на другой сервер и отказ от xen-подложки, т.е. без виртуальной машины ща работает. Другие виртуалки на той-же винде на том-же сервере нормально работают, не перезагружаются. Майкросовтовские продукты могут неожиданно себя вести при каких-то железных сбоях и вообще ничего не сообщать и в логи не писать. А по поводу лечения - базу с бэкапа на новом серваке поднять.
40. Александр Цегельников (markers) 25.02.10 07:28
Любые статьи и комментарии по этой теме и по существу, весьма полезны! Подчерпнул пару полезностей из статьи и коментов! Всем спасибо! Больше бы таких статей и коментов!
41. Vitaliy (idef) 25.02.10 12:43
Мда, расчет по ограничению памяти сервера действительно спорный получился.
А какие есть мнения по поводу параметра "Max Degree of Parallelism" :?:
Это напрямую должно влиять на производительность.
42. glinmn1 glinmn1 (glinmn1) 26.02.10 11:32
Дык по английски мы читать не умеем!!!
А восстановление заняло 5 минут. Всего лишь упал Log у Master.
Какой переезд на другой сервер, какой ребут, я же писал магазин, работающий 24 часа

А вообще по жизни, был хороший ресурс, но теперь для поднятия рейтинга постят ВСЕ. Хорошо если читает грамотной, он разберется ,что к чему, а новичек, прочтет сделает по данной схеме получит геморой в лучшем случае или увольнение после очередного падения сервера
Читайте и думайте.

43. Алексей Новоселов (a-novoselov) 27.02.10 07:17
(42) Конечно надо в первую очередь логи SQL посмотреть, а не одно сообщение хз откуда.
Ресурс стараемся поднимать, статья впервую очередь была написана как хорошая тема для обсуждения, для того, чтобы народ делился опытом. Если можете какие-то тезисы опровергнуть, то говорите. Если можете написать лучше - пожалуйста. Здесь я ни одной подобной статьи не встречал, вот и решил написать.
44. Алексей Новоселов (a-novoselov) 27.02.10 07:20
(42) Что в настройках вам не нравится? Из-за чего при таких настройках может упасть сервер? При чем тут падение лога у мастера, если тут про настройки системных таблиц вообще ничего не говорится?
45. Sergey Wind (qSerik) 27.02.10 09:58
Почти к такому же алгоритму построения SQL пришел сам еще задолго до данной статьи, по алгоритму все хорошо, еще добавил ежечастно очистку процедурного кеша, а остальное почти по алгоритму автора, по этому однозначно + и статья имеет достойное место быть вне зависимости от некоторых комментов! Побольше бы таких заний писали, а не негативной критики!
46. Сергей (Che) Коцюра (CheBurator) 02.03.10 00:16
(45)
еще добавил ежечастно очистку процедурного кеша,

- что это такое и как делается?
47. Sergey Wind (qSerik) 02.03.10 09:30
(46) В агенте выставляется команда для базы
DBCC FREEPROCCACHE
Удобно раз в час, описание можно найти на официальном сайте, выполнять команду рекомендует 1С.
Astartes; a-novoselov; +2 Ответить 1
48. gilv (Gilev.Vyacheslav) 02.03.10 16:45
(47) пока ссылку на офицальном сайте, что это рекомендуется все делать
ты хотя бы понимаешь, что удаляешь скомпилированные запросы этим ?
rboy; ojiojiowka; a-novoselov; +3 Ответить 1
49. Алексей Новоселов (a-novoselov) 02.03.10 17:11
(48) Во время сбора статистики кэш автоматически чиститься? Для проверки надо включить, потестить как оно отрабатывать будет.
50. Тимофей Бугаевский (boogie) 05.03.10 18:24
Можно ламмерский коммент?
36 гигов оперативки на сервере это круутааа :) У нас 2 гига и Win2003. Так и живём :{}
51. dushelov (Душелов) 05.03.10 20:18
(50) Тут коммерческому предприятию гордиться нечем. У большинства ноутбуки уже мощнее будут.
52. gilv (Gilev.Vyacheslav) 06.03.10 15:12
(49) причем тут статистика и кэш?
надо просто понимать рекомендации, а не только тупо их выполнять
если объем данных изменяется не сильно, то очистка процедурного кэша скорее зло, так как скулю придется компилировать запрос заново

именно поэтому у админов есть термины типа "прогретый кэш", потому что все необходимые данные подняты в кэш и скомпилированы запросы
т.е. при первом запуске когда кэши "холодные" запросы исполняются дольше

резюмирую: процедурный кэш надо чистить не ради чистки, а если вы видите что система очень сильно загруженно и очитска кэша ускоряет общую производительность (т.е. когда заново скомплированный запрос работает с новыми условиями типа статистики, объемов строк, индексами и т.п.)
53. Алексей Новоселов (a-novoselov) 07.03.10 10:17
(52) Включил очистку раз в сутки система начала тормозить по утрам. Полезная фича получается, если делать ее раз в неделю (после переиндексации) - скомпилированные запросы ссылаются на старые индексы и очистка кеша ускоряет работу.
54. Ден (lion11) 05.05.10 13:24
А разве Полная переиндексация не включает в себя Дефрагментацию индексов?
55. gilv (Gilev.Vyacheslav) 05.05.10 13:29
(54) я не знаю что значит Полная,
перестройка индексов - это удаление индекса и создание его заново.
После этой процедуры дефрагментировать дополнительно нечего, уже все упорядочено в момент создания.
56. Ден (lion11) 05.05.10 15:09
(55) Я так понимаю, что под Полной автор имел ввиду "Rebuild Index", а дефрагментация - это "Reorganize Index". Вот меня и смутила фраза "...естественно после полной переиндексации сразу же делается дефрагментация индексов и обновление статистики." - это уже не требуется.
57. gilv (Gilev.Vyacheslav) 05.05.10 17:29
(56) вот поэтому я думаю, что статья называется "как правильно" слегка неадекватно, скорее опыт удачной настройки :)
58. Ден (lion11) 06.05.10 12:22
Тем не менее - статья очень полезная! Плюсы заслуженные!
59. gilv (Gilev.Vyacheslav) 06.05.10 14:32
(58) полезность штука субъективная,
вот http://kb.1c.ru/articleView.jsp?id=13 куда правильней называется "регламентные операции", а не как правильно делать регламентные операции :)
60. tidex-s1 (tidex-s1) 05.07.10 17:39
(57),(59)
Молодец! и даже
Критерий оптимальности указал!!!:
1. MS SQL для круглосуточной работы
2. более, чем 200 пользователей одновременно
Все ясно и понятно если MS SQL для круглосуточной работы И более, чем 200 пользователей одновременно ----> пользуйся этой статьей.
61. Игорь Войнов (igyo) 02.09.10 04:39
Эта инструкция на 200 и больше пользователей. А что изменить в этой инструкции на 50 пользователей
62. Алексей Новоселов (a-novoselov) 02.09.10 21:42
(61) Это инструкция по оптимальной настройке MS SQL для работы с 1С при любом количестве пользователей. Просто если работают 10 пользователей и вводят по 2 документа в день, пойдет просто файловый вариант или скуль с настройками по умолчанию.
63. gilv (Gilev.Vyacheslav) 03.09.10 10:08
(63) на 1000 пользователей с такими настройками скуль просядет, тем более что на таких масштабах настройки базы также начинают играть ключевую роль!
64. gilv (Gilev.Vyacheslav) 03.09.10 10:10
(61) я бы занизил количество соединений в параметрах как минимум
65. Алексей Новоселов (a-novoselov) 03.09.10 11:41
(63) А не могли бы подсказать, какие настройки необходимо поменять на 1000 пользователей? Из-за чего скуль просядет? Поможет ли скуль при работе с 1С "ALTER DATABASE Database SET ALLOW_SNAPSHOT_ISOLATION ON;" для уменьшения количества блокировок?
66. gilv (Gilev.Vyacheslav) 03.09.10 12:26
(65) нет, не хочу
то что я считал нужным расказать публично, я выкладываю на свой сайт gilev.ru
все что считаю конкурентным преимущество, я "продаю" на курсах или ввиде консалтинговых услуг

но если кто сомневается, что скуль просядет на 1000 юзерах, попробуйте сами...
ermakovaanna; Артано; +2 2 Ответить 4
67. Алексей Новоселов (a-novoselov) 05.09.10 14:03
(66) Интересно, что вы преподаете такое на курсах, если про вас говорят пацаны из Олми, что вы код ногами пишите?
68. gilv (Gilev.Vyacheslav) 05.09.10 15:08
(67) Напишите на почту gilev.ru собачка gmail.com, что КОНКРЕТНО Вас интересует. Я попробую ответить.
Надеюсь, не путаете меня с однофамильцем http://www.spec8.ru/
69. Алексей Новоселов (a-novoselov) 11.09.10 02:35
(68) Да, похоже действительно однофамилец.
70. 1Це (1Це) 23.11.10 11:22
(66) это конечно может быть и верно, но уже не первый раз замечаю, что вы влазите в ветку, начинаете говорить что все неправильно, и что вы знаете как сделать лучше в разы. При этом по делу - ноль, одни туманные фразы типа "скуль просядет", а почему просядет - это уже за деньги. Если это ваш способ рекламы, то он, мягко говоря, гниловат. Если вы решаете написать в ветку, будьте готовы подтвердить вашу критику дельными советами, а если ваша цель - завлечь людей на свой консалтинг, то завлекайте на своем сайте, нефиг тут воду мутить.
shagua; sheffchik; jan27; Tavalik; Fr1eNd_Tver; kross11; Lapitskiy; baracuda; u_n_k_n_o_w_n; paybaseme; ram3; jake_qwert; igor.ofitserov; jack_kkm; nSpirit2; rhtr; Jimkaaa; Di-dog; Caligare; IgorKox; RodinMax; yuzer_666; aziat71; Roman100; xzorkiix; mataranga; HiGHT; mixsture; rasswet; dunaev.anton; gmkushkunov; DMSDeveloper; +32 Ответить
71. Mihail D (dmv78) 23.02.11 18:40
то что надо как раз! Спасибо автору!
72. Алекс Господин (Cat-MF) 24.08.11 11:38
В настройках базы на скрине выключена корреляция дат. ИМХО, надо бы включить.
73. PlatonovStepan (Jogeedae) 12.09.11 09:57
про Максимальное количество потоков по-умолчанию ссылка:
MSSQL max worker threads на msdn

Вроде неплохие базовые настройки, плохо конечно, что без описания почему-куда, тут gilv верно отметил.
74. Инна (westinka) 22.11.11 14:33
спасибо автору, т.к. настройка скл сервера это явно опыт, когда ты поняла косяки и их правишь. а если не знаешь, да в основном в статьях используют типовые, то конечно ошибаешься
75. Наталия Мастербатова (zzz_natali) 09.12.11 08:52
Почему в настройках базы Auto Shrink стоит False, а не True?
Я обычно взвожу этот флаг.
76. Алексей Новоселов (a-novoselov) 09.12.11 10:35
(75) Shrink базы данных довольно затратная процедура, при круглосуточной работе пользователей тормозит базу и мешает людям работать. Если БД постоянно растет, смысла в этой процедуре вообще нет, т.к. SQL использует сперва уже выделенное под БД освободившееся дисковое пространство. Да и выделение нового пространства после Shrink'а затратная процедура... Вобщем, при необходимости (свертка или чистка неиспользуемых регистров) сжать файлы можно и вручную.
Serg0FFan; +1 Ответить
77. Андрей - (Motor24) 12.12.11 17:18
Спасибо за статью, думал, что настроил свой вариант "скуль+восьмерка" нормально - ан нет, пойду вносить коррективы.
78. Андрей Иванов (Jackman) 19.12.11 20:56
Спасибо. Лишний раз, для спокойствия, перепроверил параметры скуля.

Кстати, встречалась информация, что связка WinServer2008+MSSQL2008R2+1C8.1 (да и 8.2) дают значительно большие тормоза, чем более ранние версии скуля и винды. Даже тесты делались, дважды тестировали на одном железе, но с разным софтом:

1
Win2003 (32bit) + SQL 2005
Первый тестовый запуск 3:30
Второй тестовый запуск 2:30

2
Win2003 (32bit) + SQL 2005 + оптимизации
Первый тестовый запуск 3:30
Второй тестовый запуск 2:30

3
Win2008R2 + SQL 2008 + 1C x64
Первый тестовый запуск 5:30
Второй тестовый запуск 4:30

4
Win2008R2 + SQL 2008 + 1C x86
Первый тестовый запуск 5:30
Второй тестовый запуск 4:30

5
Win2008R2 + SQL 2005 + 1C x64
Первый тестовый запуск 5:20
Второй тестовый запуск 4:15

6
Win2008R2 + SQL 2005 + 1C x86
Первый тестовый запуск 5:20
Второй тестовый запуск 4:15

7
Win2003 (32bit) + SQL 2005
Первый тестовый запуск 3:15
Второй тестовый запуск 2:20
solarstrike; +1 Ответить 2
79. Андрей Вовк (wowkai) 29.12.11 12:19
спасибо за статтю. а как часто нужно делать дефрагментацию дисков с БД и логом? или нужно вобще?
80. Serg0FFan (Serg0FFan) 29.12.11 12:22
(78) Jackman, интересно, а
Win2003R2(х64) + SQL 2005 + 1C x64
какие показатели выдаст?
81. CCC CCC (profych1) 29.12.11 12:26
82. Алексей Новоселов (a-novoselov) 29.12.11 13:37
(79) Для файловой системы NTFS дефрагментация в принципе не обязательна. Да и на FAT она дает прирост производительности когда часто записывается / удаляется / перезаписывается большое количество мелких файлов. А база данных храниться в двух больших файлах, дефрагментация ничем не поможет.

(78) (80) Здесь же на инфостарте встречал публикацию (правда найти сейчас не могу, может быть так-же в комментариях было где-то), в которой говорилось о том, что Win 2008x64 + SQL 2008x64 дают большую производительность, чем 2003. Насколько я знаю в 2008 винде очень сильно переписана процедура работы с файловой системой, ускоряющая работу с файлами если не на порядок, то в разы точно. И результаты таких тестов являются частным случаем для конкретного оборудования. Если на сервере 2 ГБ памяти, то и дибилу понятно что поставив туда 2008-е вин и скуль, вы снизите производительность в разы, по сравнению с 2003-ми.
Вобщем желательно самому на своем оборудовании протестировать и решить с чем работать комфортнее. Да и поддержка M$, обновления и т.п. для 2008-х покачественнее, ИМХО.
83. Наталия Мастербатова (zzz_natali) 29.12.11 13:41
a-novoselov пишет:(79) Для файловой системы NTFS дефрагментация в принципе не обязательна. Да и на FAT она дает прирост производительности когда часто записывается / удаляется / перезаписывается большое количество мелких файлов.

Батенька, Вы бы хоть ИМХО добавляли, чтобы безапелляционно делать такие утверждения. Не нужен дефраг на современных винтах с размером больше терабайта? ну-ну... :)
84. Алексей Новоселов (a-novoselov) 29.12.11 13:58
(83) Какая разница какого размера диски? Это же не файловый сервер, а сервер БД.

Вот интересная статья про NTFS:


В самом начале утверждалось, что NTFS не подвержена фрагментации файлов. Это оказалось не совсем так, и утверждение сменили - NTFS препятствует фрагментации. Оказалось, что и это не совсем так. То есть она, конечно, препятствует, но толк от этого близок к нулю... Сейчас уже понятно, что NTFS - система, которая как никакая другая предрасположена к фрагментации, что бы не утверждалось официально. Единственное что - логически она не очень от этого страдает. Все внутренние структуры построены таким образом, что фрагментация не мешает быстро находить фрагменты данных. Но от физического последствия фрагментации - лишних движений головок - она, конечно, не спасает. И поэтому - вперед и с песней...
--------------------------------------------------------------------------------
NTFS - очень экономная система. Размер кластеров в ней разумно минимален - обычно это 4 кб (на стандартных сейчас дисках в десяток-другой гигабайт). Как известно, система сильнее всего фрагментирует файлы когда свободное место кончается, когда приходится использовать мелкие дырки, оставшиеся от других файлов. Тут возникает первое свойство NTFS, которое прямо способствует серьезной фрагментации.
Диск NTFS поделен на две зоны. В начала диска идет MFT зона - зона, куда растет MFT, Master File Table. Зона занимает минимум 12% диска, и запись данных в эту зону невозможна. Это сделано для того, чтобы не фрагментировался хотя бы MFT. Но когда весь остальной диск заполняется - зона сокращается ровно в два раза icon_smile.gif. И так далее. Таким образом мы имеем не один заход окончания диска, а несколько. В результате если NTFS работает при диске, заполненном на около 90% - фрагментация растет как бешенная.

• Попутное следствие - диск, заполненный более чем на 88%, дефрагментировать почти невозможно - даже API дефрагментации не может перемещать данные в MFT зону. Может оказаться так, что у нас не будет свободного места для маневра.

Далее. NTFS работает себе и работает, и всё таки фрагментируется. Этому способствует странный алгоритм нахождения свободного места - второе серьезное упущение. Если файл пишется большими кусками - всё нормально. Но если файл медленно растет - алгоритм такой: берется какой-то определенный объем диска и заполняется файлом до упора. Причем по очень интересному алгоритму: сначала заполняются большие дырки, потом маленькие. Т.е. типичное распределение фрагментов файла по размеру на фрагментированной NTFS выглядит так (размеры фрагментов):
16 - 16 - 16 - 16 - 16 - [скачек назад] - 15 - 15 - 15 - [назад] - 14 - 14 - 14 .... 1 - 1 - 1 -1 - 1...
Так процесс идет до самых мелких дырок в 1 кластер, несмотря на то, что на диске наверняка есть и гораздо более большие куски свободного места.

Может быть я забыл написать что-то еще... Смысл в том, что никак нельзя сказать, что NTFS препятствует фрагментации файлов. Наоборот, она с радостью их фрагментирует. Фрагментация NTFS через пол года работы доведет до искреннего удивления любого человека, знакомого с работой файловой системой. Поэтому приходится запускать дефрагментатор. Но на этом все наши проблемы не заканчиваются, а, увы, только начинаются...
--------------------------------------------------------------------------------
В NT существует стандартное API дефрагментации. Обладающее интересным ограничением для перемещения блоков файлов: за один раз можно перемещать не менее 16 кластеров (!), причем начинаться эти кластеры должны с позиции, кратной 16 кластерам в файле. В общем, операция осуществляется исключительно по 16 кластеров. Следствия:

• В дырку свободного места менее 16 кластеров нельзя ничего переместить (кроме сжатых файлов, но это тонкости).

• Файл, будучи перемещенный в друге место, оставляет после себя (на новом месте) "временно занятое место", дополняющее его по размеру до кратности 16 кластерам.

• При попытке как-то неправильно ("не кратно 16") переместить файл результат часто непредсказуем. Что-то округляется, что-то просто не перемещается.. Тем не менее, всё место действия щедро рассыпается "временно занятым местом". Наверное о нас заботятся, чтобы мы отстали от этого места - чтобы алгоритм дефрагментации не клинило. icon_smile.gif

• "Временно занятое место" освобождается через некоторое время, обычно где-то пол минуты. Гы.

Тем не менее, логично было бы использовать это API. Его и используют. Поэтому процесс стандартной дефрагментации, с поправками на ограниченность API, идет следующими фазами, не обязательно в этом порядке:

• Вынимание файлов из MFT зоны. Не специально - просто обратно туда их положить не представляется возможным. Безобидная фаза, и даже в чем то полезная.

• Дефрагментация файлов. Безусловно полезный процесс, несколько правда осложняемый ограничениями кратности перемещений - файлы часто приходится перекладывать сильнее, чем это было бы логично сделать по уму.

• Дефрагментация MFT, виртуалки (pagefile.sys) и каталогов. Возможна через API только в Windows2000, иначе - при перезагрузке, отдельным процессом, как в Diskeeper-е.

• Складывание файлов ближе к началу - так называемая дефрагментация свободного места. Вот это - воистину страшный процесс...

Допустим, мы хотим положить файлы подряд в начало диска. Кладем один файл. Он оставляет хвост занятости дополнения до кратности 16. Кладем следующий - после хвоста, естественно. Через некоторое время, по освобождению хвоста, имеем дырку <16 кластеров размером. Которую потом невозможно заполнить через API дефрагментации! В результате, до оптимизации картина свободного места выглядела так: много дырок примерно одинакового размера. После оптимизации - одна дыра в конце диска, и много маленьких ><16 кластеров дырок в заполненном файлами участке. Какие места в первую очередь заполняются? Правильно, находящиеся ближе к началу диска мелкие дырки ><16 кластеров... Любой файл, плавно созданный на прооптимизированном диске, будет состоять из дикого числа фрагментов. Да, диск потом можно оптимизировать снова. А потом еще раз.. и еще.. и так - желательно каждую неделю. Бред? Реальность.>

Таким образом, имеется два примерно равнозначных варианта. Первый - часто оптимизировать диск таким дефрагментатором, смиряясь при этом с дикой фрагментацией заново созданных файлов. Второй вариант - вообще ничего не трогать, и смириться с равномерной, но гораздо более слабой фрагментацией всех файлов на диске.

Пока есть один дефрагментатор, который игнорирует API дефрагментации и работает как-то более напрямую - Norton Speeddisk 5.0 для NT. Когда его пытаются сравнить со всеми остальными - Diskeeper, O&O defrag, т.д. - не упоминают этого главного, самого принципиального, отличия. Просто потому, что эта проблема тщательно скрывается, по крайней мере уж точно не афишируется на каждом шагу. Speeddisk - единственная на сегодняшний день программа, которая может оптимизировать диск полностью, не создавая маленьких незаполненных фрагментов свободного места. Стоит добавить также, что стандартное API не может дефрагментировать тома NTFS с кластером более 4 Кбайт - а SpeedDisk, по прежнему, может.

К сожалению, в Windows 2000 засунули дефрагментатор, который работает через API, и соответственно плодит дырки <16 кластеров. Так что как только появится (если уже не появился) - так сразу надо качать Speeddisk для W2k. Как некоторый вывод из всего этого - все остальные дефрагментаторы при одноразовом применении просто >вредны. Если вы запускали его хоть раз - нужно запускать его потом хотя бы раз в месяц, чтобы избавится от фрагментации новоприбывающих файлов. В этом основная суть сложности дефрагментации NTFS теми средствами, которые сложились исторически.




Общий вывод: если начнете делать дефрагментацию, то ее необходимо будет делать постоянно, иначе начнутся тормоза.
ИМХО вывод: Нахрена она нужна если на быстродействии базы это никак не скажется, т.к. база лежит (у грамотных админов) на отдельном от системы и TEMP'а диске одним(двумя) файлами. Это как иконка в автомобиле - если с ней вы чувствуете себя спокойнее, то весить надо обязательно, т.к. уверенность в себе водителя за рулем помогает безаварийному вождению.
85. Наталия Мастербатова (zzz_natali) 29.12.11 14:05
Какая разница какого размера диски? Это же не файловый сервер, а сервер БД.

ага, посмотрю как головки будут хрустеть, когда идет полнотекстовый поиск на базёнке размером под сто гектар (волею судеб распухшей вперемешку с другим хламом на разделе)...
86. Алексей Новоселов (a-novoselov) 29.12.11 14:27
(85) Ставь RAID и хрусти веселей ;) дефрагментация тебе не поможет, т.к. ФАЙЛ БД ОДИН, и головки будут летать +- 100ГБ пространства что при фрагментированном файле, что при файле одним куском. И не храни хлам рядом с базой. С хламом после дефрагментации все равно дырки останутся из-за особенностей файловой системы.
87. Наталия Мастербатова (zzz_natali) 29.12.11 14:38
a-novoselov Ставь RAID и хрусти веселей ;) дефрагментация тебе не поможет, т.к. ФАЙЛ БД ОДИН, и головки будут летать

Я ему про Фому, он мне про Ерёму! Когда на разделе стоит несколько баз и они начинают пухнуть исторически, они по-любасу жирнеть будут паззлами! Если диск не дефражить, то они так и будут кусками по винту расплёснуты. Имейте мужество вести конструктивный диалог и не надо "ты"кать и переходить на панибратчину.
В конце концов, я же женщина... пусть и СИСЯСдминка. )))
88. Алексей Новоселов (a-novoselov) 29.12.11 15:05
(87) Простите, матушка, отнюдь к вам только на "Вы". Все же, матушка, держать несколько больших баз, критичных к скорости операций, не на рэйде - может быть конечно и не показатель уровня квалификации сисадмина, а показатель дикой жадности начальства, тогда согласен, кроме дефрагментации и молитв Вас уже ничего не спасет. Вы абсолютно правы.
89. Наталия Мастербатова (zzz_natali) 29.12.11 15:24
(88) a-novoselov,
Лана, проехали... разрешаю выпить со мной бокальчик на брудер... ))
Между прочим, я у себя дома чисто субъективно ощущаю разницу скорости работы нулевого райда (пусть и миллион раз отдефрагментированного), если на нем запущена операционка обычно.
И есть разница и весьма существенная, если с этого же райда, но в режиме vhd (кусок 50 гектар).
90. Алекс Ю (AlexO) 02.01.12 04:38
(86) вам правильно указали, что дефрагментация нужна:
1) если база стоит с ОС
2) если база не одна, а SQL обслуживает еще много чего.
Когда есть отдельный РЭЙД только под базу, есть возможность этот рейд "защищать" от вопросов начальства ("а че это у вас пустой рэйд токо с одной базой!?") - замечательно.
Но именно это нужно указать в примечаниях к "дефрагментация не нужна!"
Дефрагментация - это накладные расходы использовыания файловых систем виндовс, в линуксах и прочих никсах создатели ФС заранее постарались свести к минимуму как саму фрагментацию, так и её последствия.
Т.е. опять же, кто сидит на 1С и Линуксе (Posgre) - тоже могут об дефрагментации не думать.
91. Leo K (solarstrike) 03.01.12 14:10
Полезная статья. Однако.
92. Алексей Новоселов (a-novoselov) 06.01.12 11:00
(90) Да я же согласился, что дама права.
93. Светялчок (Масянечка) 10.01.12 22:24
Спасибо, очень полезно и познавательно. Исправила свои настройки)
94. Игорь Юртаев (ipyu) 10.01.12 22:33
Спасибо, просто и доходчиво.
95. Андрей - (Motor24) 24.01.12 12:02
Спасибо - сервер "задышал" после изменений. Действительно, мало поставить SQL - надо грамотно настроить его под каждый, индивидуальный случай. В моем случае очень помогло ограничение аппетитов SQL по оперативке и дефрагментация индексов. Машина далеко не мощная, хоть и "урожденный сервер": Intel-овская мать S3200SH, двухъядерный же Intel по 2,66 Ггц и 8 Гб оперативки. Далеко не фонтан, но с ролью SQL и 1С 8.2 сервера на 20 баз и 40 пользователей справляется.
Прирост по скорости ощутим, еще раз спасибо за статью! Также очень много полезного почерпнул из развернувшейся в комментариях дискуссии. :)
96. Александр Шустов (Olfost) 25.01.12 09:52
У нас в конторе Posgris SQL и работает под Федорой. Все вроде нормально.
В филиале сервер MSSQL .. постоянно какие то косяки. То памяти не хватает, то просто вырубается 1С ка.
97. Алексей Новоселов (a-novoselov) 25.01.12 10:11
(96) Обновления с Microsoft Update для винды (фреймворки всякие и т.п.) и скуля все стоят? Посмотрите в журнале событий Windows из-за какого модуля 1С-ка валится, если из-за какой-нибудь библиотеки типа "C:\Windows\system32\ms_string_funcs.dll", то обновления 99% должны помочь.
ПС: название библиотеки придумал сам, в винде такой нету)
98. Ирек Бикмухаметов (xbic) 30.01.12 10:41
99. Александр Шустов (Olfost) 01.02.12 08:05
Спасибо, попробую. Хотя филиал вроде закрывают и проблема исчезнет сама собой.
У нас в Головняке под Федорой 1С сервер крутится.