0. MrWonder 580 29.01.19 09:23 Сейчас в теме

Инструкция: ускоряем tempdb переносом в RAM диск

При работе 1С:Предприятия 8 в режиме клиент-сервер широко используются временные таблицы. Кроме того, TEMPDB используется Microsoft SQL Server при выполнении запросов, использующих операторы GROUP BY, UNION, DISTINCT и т.п. Эта служебная БД весьма нагружена и её ускорение сулит нам серьезный выигрыш в производительности. Давайте же поместим её в RAM.

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. collider 29.01.19 09:32 Сейчас в теме
Эх! А я-то думал, что в статье будет описано, как именно сделать на сервере RAM-диск.
Какой понадёжнее, какой подешевле и т.п.
myxins1989; sansys; Tavalik; alest; +4 Ответить
5. MrWonder 580 29.01.19 10:39 Сейчас в теме
(1) Ниже написал, каким диском пользуюсь.
Вопросы установки и настройки нужно рассмотреть?
6. collider 29.01.19 10:42 Сейчас в теме
(5) Да не. Разобраться с установкой там легко.
Просто пишу свой отзыв о статье.
Я рассчитывал на сравнительный анализ ПО для RAM-дисков, а статья оказалась о другом. :)
2. AntonSm 26 29.01.19 09:32 Сейчас в теме
Ответьте, пожалуйста, с помощью какой программы вы делали RAM-диск?
3. reboot 24 29.01.19 09:55 Сейчас в теме
(2) imDisk Toolkit - как пример из статьи.
4. MrWonder 580 29.01.19 10:38 Сейчас в теме
(2) https://www.softperfect.com/products/ramdisk/
Можете найти старую бесплатную версию
10. user774630 29.01.19 11:09 Сейчас в теме
(8) а теперь 2 тыщи домашняя версия и чуть больше 3к - коммерческая. Для организации копейки, так-то.
11. AntonSm 26 29.01.19 11:11 Сейчас в теме
(4) Интерес скорее вызывает не столько цена, сколько опыт эксплуатации.
У вас это на рабочей базе/базах?
И нормально работает?
collider; +1 Ответить
13. MrWonder 580 29.01.19 11:44 Сейчас в теме
(11) не нормально, а великолепно.
7. herfis 285 29.01.19 10:54 Сейчас в теме
Плюсанул за разнесение по файлам для решения проблемы переполнения.
Вроде банальная штука, но почему-то никогда в голову не приходила. Правда и вопрос этот всерьез не рассматривал.
redtram; user774630; +2 Ответить
9. AntonSm 26 29.01.19 11:09 Сейчас в теме
(7) А знаете, сколько рекомендуется создавать файлов tempdb?
Ответ по ссылке - https://its.1c.ru/db/metod8dev#content:5904:hdoc
15. herfis 285 29.01.19 11:59 Сейчас в теме
(9) Хм... И за счет чего ожидается прирост, если файлики рядом лежат?
Да и выставлять степень параллелизма в единицу - тоже спорный совет. Это радикально замедляет формирование тяжелых отчетов.
ЗЫ. Почитал про разбиение tempdb - это скорее прикрытие возможного узкого места (при большом количестве конфликтов при мультипоточном доступе к файлу), чем кнопка "турбо". Т.е. может и не иметь никакого эффекта.
16. MrWonder 580 29.01.19 12:09 Сейчас в теме
(15) Правильно ли я понял Ваш вопрос - за счёт чего возникает прирост производительности после перемещения tempDB в RAM. Верно?
21. herfis 285 29.01.19 15:17 Сейчас в теме
(16) Нет. Вопрос касался разделения tempdb на несколько файлов на одном и том же диске. Вопрос был не к вам.
Но если знаете точный ответ - буду благодарен. И актуальна ли эта рекомендация для RAID 5 и выше.
17. MrWonder 580 29.01.19 12:10 Сейчас в теме
(9) Конечно знаю. Но в данной ситуации рекомендация разбивать неприменима. Нужно ли объяснить, почему?
49. nvv1970 30.01.19 15:17 Сейчас в теме
(9) Не правильно давать ссылку на "перепосты", а не на первоисточник.
Плохо, что для 1С-ников истина по SQL на сайте 1С, а не на MSDN ((((
12. AnderWonder 21 29.01.19 11:14 Сейчас в теме
MS SQL сам кэширует в памяти все что нужно без всяких RAM-дисков. Без тестов производительности статья ни о чем. Разбивать TempDB на несколько файлов - описано в настройках MS SQL от 1С, вероятно закрытие месяца от этого и ускорилось.
Eret1k; GreenDragon; kote; +3 Ответить
14. MrWonder 580 29.01.19 11:45 Сейчас в теме
(12) Спасибо за Ваш ответ. Держите меня в курсе.
27. Glebis 11 29.01.19 17:13 Сейчас в теме
(12) Я не являюсь экспертом по SQL, но насколько мне известно есть куча настроек (хеширование, статистика), которые отвечают за скорость работы с данными, ХРАНЯЩИМИСЯ НЕПОСРЕДСТВЕННО в базе (файле MDF). Но эти настройки (ИМХО) не ускоряют работы с файлами TempDB, которые (источник этой информации указать не могу) не планировались в роли оперативного хранилище здоровенных массивов информации, как сейчас их использует платформа 1С.
69. myxins1989 110 22.04.19 11:05 Сейчас в теме
(12)

MS SQL сам кэширует в памяти все что нужно без всяких RAM-дисков.


MS SQL при построении плана запроса рассчитывает необходимое количество памяти и, если ошибается, то начинает задействовать tempdb. Это легко увидеть, если в профайлере получить планы запросов. Там, где стоит желтый восклицательный знак, там внутри как раз и пишет, что был задействован tempdb. Часто такое происходит на процедурах сортировки.
AnderWonder; +1 Ответить
18. capitan 1341 29.01.19 12:22 Сейчас в теме
Было такое, как по изначальной статье, даже базы выносили, но потом все равно на ssd перешли.
Тем более в новых скулях есть настройки Buffer Pool Extension.
Как вы после перезагрузки сервера действуете или MSSQL в отложенном запуске?
19. MrWonder 580 29.01.19 12:32 Сейчас в теме
(18) В отложенном. SoftPerfect Ramdisk умеет после перезагрузки восстанавливаться. Даже с содержимым.
За рекламу бы с них, поправиться, для бывшего регента ))
20. Darklight 20 29.01.19 15:11 Сейчас в теме
Да, конечно от статьи ждал большего. Хотелось бы анализа причин, прироста производительности. Ну, простите меня, не ведующего, ну не могу я понять, почему если от SQL сервера откусить несколько десятков гигабайт памяти и сделать на них RAM-диск, то операции на этом сервере станут выполнять ЗАМЕТНО быстрее (и уж тем более в общем случае, а не как у автора - в частном случае закрытия месяца).

Ведь, насколько я знаю, все операции над temdb SQL сервер и так делает над таблицами (условно будем считать всё, что хранится в tembdb таблицами) с установленным внутренним приоритетом хранения в оперативной памяти (если её конечно достаточно)! То есть, временная таблица не будет выгружаться на диск, если для неё достаточно свободного места в оперативной памяти. Понятно, что если будут обрабатываться достаточно большие таблицы - они будут выгружаться на диск (при этом будет дублирование - часть данных наборов страниц будет в оперативном кеше и на диске). Но насколько же это будет в общем случае критично? Чтобы лишать SQL сервер гибко управлять всей своей свободной памятью, ради того, чтобы достаточно большая часть была всегда выделена под RAM диск с temdb - которая, скорее всего, в 90% не будет использована и на половину (а что будет использовано ещё и будет частично повторно кешировано в буфере SQL Server - неэффективно расходуя оперативную память на свои копии данных)! Так как SQL Server и всё-равно будет стараться держать временные таблицы в оставшейся у него оперативной памяти и выгружать их RMA-tempdb (причём выполняя объёмную пересылку данных между блоками памяти самым не производительным способом - через кучу посредников и между изолированными доменами приложений) в одну и в другую сторону только по мере необходимости (нехватки памяти, которая как раз и будет вызвана тем, что её попросту недодали SQL Server'у).

На мой взгляд RAM-диск для базы - это больше экстремальное экспериментирование, чем реальное предложение по ускорению! Вы вот так насоветуете админам - а они на своих серверах с 64Gb оперативной памяти, при базе(ах) объёмом боле 1Tb (с самой большой базой около 100Gb) и temdb, который у них при закрытии месяца пухнет свыше 100Gb возьму и выделять под RAM-tempdb минимум 16Gb (а кто-то и все 32Gb) и тем самым у них просядет обычная работа с данными рабочих баз на 25% (условно) в обычном режиме (а в пике ещё больше), а скорость работы с temdb (в часы макс нагрузки) увеличится ну максимум на 20% (и это в пике) - будет ли это реальной панацеей? Большой вопрос! Очень большой!

Тут в статье нужно было писать про исследования, которые должны были предварять такие вот серьёзные перераспределения ресурсов. Показывать где и как возникают узкие горлышки использования temdb. Обосновывать (с конкретными доводами тестов) когда и почему стоит отнимать буферную память от SQL сервера и отдавать её temdb.

И главное, в чём будет реальный экономический выигрыш - от того, что сервер будет требовать больше очень недешёвой серверной оперативной памяти, нежели - как альтернатива - просто разместить temdb на хорошем (тоже не дешёвом, но это пока с памятью не сравнить) серверном SSD диске - с высоким IOPS (лучше всего модели для PCI-ex, а не SAS/SATA; ну или хотя бы в слот M.2 - но это только на современных матерях) , и низким коэффициентом снижения производительности от числа полной перезаписи. Тут важна скорость - надёжность не так важна - это же не для хранения рабочей базы данных.

Вот тогда от статьи был бы толк...


Ну а если помещать в RAM tempdb - то я был начал только с лога temdb - который только пишется (и перезаписывается) в simple rec. mode, ему не требуется хранить большие объёмы дублирующихся данных. А данные временных таблиц - пусть SQL Server сам размещает в доступной ему буферной памяти, и выгружает на физ диск (лучше SSD), когда памяти уж совсем не хватает (а если это часто -то лучше 100 раз задуматься о том, чтобы её нарастить - ведь если её не хватает, от её перераспределения её больше не станет).

Вообще, прежде чем переходить на RAM - лучше сначала освоить перенос temdb на другой диск - если Ваш tempdb находится в том же RAID массиве что и диски рабочей базы - то задумайтесь сначала об этом, крайне негативном факторе - вынесите tempdb на отдельный RAID массив, да хотя бы просто на отдельный диск (два диска : данные и лог) и Вы сразу почувствуете прирост скорости, особенно в пиковой нагрузке! А уж если вы выберите для temdb PСI-ex SSD диски - то, наверняка, дальнейшее желание переносить их на RAM у Вас уже пропадёт!
Starik; vvp117; GreenDragon; d4rkmesa; akim2040; user1144316; alest; Sanya1984; smallbuk; Dragonim; Rusmus; strrike; lohmatik; CSiER; mickey.1cx; nyam-nyam; mivari; kolya_tlt; MrWonder; AnderWonder; rintik; +21 1 Ответить
22. MrWonder 580 29.01.19 15:42 Сейчас в теме
(20) Спасибо за Ваш развёрнутый комментарий. Он, пожалуй, размером больше моей инструкции (я не считаю это статьёй).
И писать развёрнутое исследование о том, как это выглядит и работает с разных сторон я пока не готов - времени на другие задачи остаётся мало.
Целью было лишь дать технику, которая работает и хорошо себя показала.
23. kolya_tlt 11 29.01.19 16:11 Сейчас в теме
(22) вам об этом и говорят, что нужно следовать правилу паретто - 80% думаем, 20% делаем. ваша статья - призыв не думать, а сразу делать рам диск, показала же хорошо ...
GreenDragon; +1 Ответить
30. MrWonder 580 29.01.19 17:38 Сейчас в теме
(23) Спасибо за Ваш отзыв. У меня, безусловно, есть некоторый бэкграунд в описываемой области.
Если Вам это не подходит - не используйте. Если хотите проводить тесты - проводите.
24. herfis 285 29.01.19 16:48 Сейчас в теме
(20)(23) Тут дело такое... Якобы да - сиквел сам должен грамотно справляться и что-то можно выжать грамотными настройками. И сами мелкомягкие относительно применения рам-дисков отзываются с осторожностью. Если не с осуждением. Мол двойное кэширование получается и все такое... Но вот сколько народ пробует - на практике получает неизменно отличные результаты :) Можно пытаться списывать на криворукость народа, но не припоминаю ни одного случая чтобы какой-нибудь эксперт попробовал и сказал - фигня эти ваши рам-диски, и без них можно настроить не хуже.
28. Darklight 20 29.01.19 17:24 Сейчас в теме
(24)Вот поэтому я и ратую за то, чтобы тут нормальную статью написали - с анализом, а не не просто "стало быстрее" - а если бы эксперт разбралася с тем что было и с тем что стало - может оно уже и не так уж офигенно вышло в результате, тем более для общего случая! А сейчас эта "статья" выглядит как ничем реальным не подкреплённый призыв "все на RAM диск" - это панацея для ускорения производительности в пиковой нагрузке. А из всех тестов - приведены два скриншота бенчмарка скоростей работы.... ээээ.... физического и RAM дисков - "две сферические лошади в вакууме меряются копытами"! Тут даже ни циферки о скорости изменения работы SQL Server - сдаётся автор всё мерил на глаз - по своим ощущениям! Тем более нет писаний конфигураций до и после! Чтобы понять за счёт чего был прирост!
31. MrWonder 580 29.01.19 17:39 Сейчас в теме
(28) Я Вам лично ничего не обещал. Если не оправдал Ваши ожидания, то дело лишь в Ваших ожиданиях.
eeeio; Krio2; acanta; +3 Ответить
26. nyam-nyam 29.01.19 17:12 Сейчас в теме
(20)Как вариант объяснения ускорения - SQL не хватает памяти на работу баз и отчёты одновременно. В этот момент он может не дать приоритет отчёту (тяжелый и долгий - скину ка я его на tempdb :) ). Вот у ускорение получается - в RAM диске всяко быстрее будет чем на HDD. Хотя накладные расходы конечно огромные получаются. Но это уже дело админа решать какой вариант его больше устроит.
29. Darklight 20 29.01.19 17:30 Сейчас в теме
(26)Поэтому чтобы делать RAM tempdb нужно реально понимать что это даст, какой будет выигрыш, в каких случаях, а в каких наоборот - будет просадка производительности! Нужны тесты, нужна статистика долговременной эксплуатации! нужны описания как всё это протестировать самостоятельно - чтобы те, кого это заинтересует сначала тоже провели тесты у себя, сравнили результаты, и уже потом принимал решение - что лучше!

Но, на мой взгляд, лучше начинать с вынесения tempdb на отдельный SSD диск(и). Если эффекта не достаточно - думать о вынесении лога транзакций tempdb в RAM. А вот, если эффекта от переноса tempdb на SSD вообще крайне недостаточно - уверен, что и вынос его на RAM диск не приведёт к заметному улучшению - а скорее даже к ухудшению - т.к. тут явно узкое место не в tempdb.

тяжелый и долгий - скину ка я его на tempdb :)

А вот эта фраза мне вообще не понятна! Не могу представить как SQL Server скидывает "отчет" (о котором понятии он вообще не знает) на tempdb. В tempdb создаются временные таблицы, результаты временных вычислений при выполнении физических операций SQL Server над данными, там хранятся кешированные результаты выполнения запросов, там хранятся данные незавершённых транзакций. Сам SQL Server туда ничего не скидывает, когда ему не хватает ресурсов.
SQL Server старается держать данные tempdb в памяти - но когда её не хватает - неиспользуемые кеши удаляются, а ещё занятые временные таблицы свопятся в файлы данных tempdb. Причём, так как автор разбивает файл tempdb на части, не факт, что это выгрузка на диск, пройдёт именно на RAM-диск. Никаких возможностей управлять тем, что важно хранить в памяти, а что можно и на физ диск сбросить - вообще нет! Это всё дело случая....

А, вот, кешированные страницы данных, в tempdb насколько я знаю, не хранятся - для этого используется буфер SQL Server - и если памяти для SQL свервера выделено мало - то значит и этот буфер будет небольшой - значит и за страницами данных SQL сервер будет чаще лазить на диск.... на физический диск с данными!

Конечно, если изначально выстраивать запросы так, чтобы использовать временные таблицы по максимуму - то от их размещения в RAM диске будет какой-то толк - но это реально нужно всю логику работы с данными под это адаптировать - 1С Предприятие 8 и её конфигурации так не умеют!
33. MrWonder 580 29.01.19 17:42 Сейчас в теме
(29) Павел, если Вам нужны тесты и статистика долговременной эксплуатации, Вы знаете что делать.
Почему Вы требуете их от меня? Я всего лишь скромный автор небольшой инструкции, не способный на удовлетворение Ваших желаний.
Ваши взгляды очень ценны. Спасибо Вам.
34. Darklight 20 29.01.19 17:47 Сейчас в теме
(33)Ничего от Вас не требую!
MrWonder; +1 Ответить
35. MrWonder 580 29.01.19 18:00 Сейчас в теме
(34) Спасибо. В качестве благодарности примите показатели io_stall_write_ms и io_stall_read_ms для TempDB в Ram и не в Ram.
37. Darklight 20 29.01.19 18:17 Сейчас в теме
(35)Вот это уже полезнее, но ненамного, коли не указаны условия, при которых собрана эта статистика. Без них - она лишь говори о том, что какая-то задача(и) чаще обращалась к файлу tempdb на диске T (RAM), чем к физическому размещению. Но это не показатель. Понятно, что к примеру, когда объём данных хранящихся tempdb априори укладывается в эту часть tempdb, размещаемую на быстром диске - sQL Server будет их размещать именно там. Но что будет, когда обороты данных будут стремительно расти и понадобится более интенсивно задействовать физ часть. Вот, например, сделайте закрытие месяца с настройками так, чтобы физ часть выросла в 2 раза больше, чем выделенная RAM часть (что покажет наличие действительно большой оборачиваемости виртуальных таблиц) - вот и посмотрим, насколько статистика обращения к RAM диску будет превосходить обращения к физ диску tempdb
А ещё, для сравнения - нужно повести ту же операцию с теми же данными (после рестарта SQL сервера для чистоты), но уже только с задействованным тем же tembdb. Ну и в идеале всё это ещё закрепить графиками использования буфера sql, числа попаданий в кеш, и аналогичной статикой обращения к данным БД - чтобы показать, что там не произошло серьёзной просадки.

ну и конечно же сделать численный замер - сколько операция выполнялась с RAM диском, и сколько без него. да и указать, сколько памяти осталось SQL серверу.
41. nyam-nyam 30.01.19 09:01 Сейчас в теме
(29)Я тоже за научный подход. Но Инфостарт не научное издание, и требовать от каждой статьи научного подхода со статистически значимыми результатами слегка наивно. Автор поделился своим решением в своей совершенно конкретной ситуации и нигде в статье не гарантировал что его подход является универсальным.
70. Sergey.Noskov 1100 22.04.19 14:18 Сейчас в теме
(20) Ну блин, столько текста и в конце противоречие самому себе.. тезис:
Ведь, насколько я знаю, все операции над temdb SQL сервер и так делает над таблицами (условно будем считать всё, что хранится в tembdb таблицами) с установленным внутренним приоритетом хранения в оперативной памяти (если её конечно достаточно)! То есть, временная таблица не будет выгружаться на диск, если для неё достаточно свободного места в оперативной памяти.


опровергается своим же опытом:
вынесите tempdb на отдельный RAID массив, да хотя бы просто на отдельный диск (два диска : данные и лог) и Вы сразу почувствуете прирост скорости, особенно в пиковой нагрузке!

Коллега, а где же исследование, где доказательства, что на отдельном массиве будет быстрее? где описание экономического выигрыша?
71. Darklight 20 22.04.19 14:42 Сейчас в теме
(70)Где противоречия?
Я написал что tempdb на отдельном массиве будет, с вероятностью близкой к 100%, заметно быстрее, чем на том же массиве, где и основные базы. И не важно - какой это будет массив - sdd, hdd, ram или ещё какой. Главное - отдельный! Для RAID ещё важно указать, что это отдельный лун.
Вот насколько будет быстрее - зависит от очень большого числа факторов. Но, чаще всего, сели был 1 физический HDD-массив, а станет 2(3) физических HDD массива (основной, tempdb data, tempdb log - tempdb разделять на разные физические диски имеет смысл только для HDD массива)- скорость действительно вырастет весьма заметно, особенно в период интенсивного формирования отчётности, и проведения регламентных операций. А, вот, вынос на RAM диск - заметного прироста производительности может и не дать (а в ряде случаев - даже привести к её снижению).
Отдельно замечу, что если всё лежало на SSD массиве - то вынос tempdb на отдельный SSD массив тоже может не дать заметного прироста производительности.
Отдельно замечу, то при испоользовании виртуализованных массивов (на СХД или на хостах виртуализации) - есть свои нюансы правильной настройки доступа к "массиву" - если настроить неправильно - то такой вынос tempdb на отдельный массив тоже может не дать прироста, и, даже наоборот, привести к снижению производительности.

Ну а если Вы ещё и баз для отчётов вынесите отдельно от базы для проводок, и настроите синхронизацию - так прирост будет ещё выше, ЗНАЧИТЕЛЬНО ВЫШЕ!

Коллега, а где же исследование, где доказательства, что на отдельном массиве будет быстрее? где описание экономического выигрыша?

Это не моя статья. Я лишь написал своё предложение исходя из имеющегося у меня опыта.
И я всего-лишь намекнул, что надо экспериментировать с разными конфигурациями в каждом конкретном случае эксплуатации - чтобы понять, что именно для Вас будет наиболее эффективно. А не тупо следовать советам того или иного советчика - типа "делай вот как я и будет тебе счастье"!
72. Sergey.Noskov 1100 22.04.19 15:32 Сейчас в теме
(71) явные противоречия, сначала топим против RAM, приводя доводы, что "все таблицы и так в памяти", а потом случай из практики - перенесите на другой диск и будет быстрее. Но если таблицы в памяти, то требования к диску и так минимальны и эффект должен быть очень слабым.
Это не моя статья. Я лишь написал своё предложение исходя из имеющегося у меня опыта.
собственно автор сделал тоже самое.
73. Darklight 20 22.04.19 15:57 Сейчас в теме
(72)"все таблицы и так в памяти" - где я такое говорил? Если бы все таблицы были в памяти то да, скорость чтения с диска была бы не важна (но вот скорость записи на диск, по-прежнему была бы важна). Но такая ситуация бывает не часто, даже для tempdb

Я лишь говорил, что таблицы tempdb MS SQL сервер старается держать в памяти, но только если для них там достаточно памяти и она не требуется для других таблиц. Вот тут-то вся загвоздка - память-то не бесконечна - и на что её выделять - на хранение всей tempdb (или её части - но это отдельная тема) в памяти (причём, порой, сразу нескольких экземпляров одних и тех же страниц данных - дублирование расхода ресурсов), и пожертвовать хранением там страниц данных других таблиц (и даже для tempdb заставлять SQL сервер гонять их туда-сюда через шину драйвера RAM диска); или на дать SQL серверу самому решать - что они будет хранить в памяти (и без лишнего дублирования), не жертвуя хранением страниц других таблиц, но получить большее проседание на операциях течение/записи данных на физический диск - когда памяти-таки не будет хватать.

А вынос tempdb на отдельный физически носитель (даже на HDD) - экономически дешевле, чем наращивание памяти на SQL сервере - и начинать стоит именно с этого - чаще всего уже этого будет вполне достаточно, особенно если это будет SSD диск. И дать SQL серверу самому управлять памятью - ему виднее, что что у него востребовано, а что нет.

Но опять-таки, я не утверждаю, что эта рекомендация верна для всех и всегда - тут нужно экспериментировать и сравнивать - у каждого свои особые условия эксплуатации СУБД!

собственно автор сделал тоже самое.

Но я не делал из своего предложения статью! Я просто контраргументировал, причём, ни разу не говорил, что выкладки автора статьи - ложные. Просто действия автора требуют глубокого понимания того, что будет в итоге - обязательного длительного тестирования. Вот это автор и не сделал (не изложил в статье; а я статью, со "своей идеей" здесь не публиковал).
74. Sergey.Noskov 1100 22.04.19 16:37 Сейчас в теме
(73) так вот же прямая цитата в (20):
Ведь, насколько я знаю, все операции над temdb SQL сервер и так делает над таблицами (условно будем считать всё, что хранится в tembdb таблицами) с установленным внутренним приоритетом хранения в оперативной памяти (если её конечно достаточно)!

в общем и в целом действительно можно провести большое исследование и проверить влияние кучи параметров и в ряде условий RAM будет полезен, в ряде вреден, всё индивидуально.
И если Вас статья подтолкнула на такую идею исследования, так welcome - сообщество спасибо скажет.
75. Darklight 20 22.04.19 17:05 Сейчас в теме
(74)Если очень внимательно прочитаете, что цитируете, то поймёте, что там написано "с приоритетом хранения в оперативной памяти (если её конечно достаточно)". И это самое важное, исключительно по моей точке зрения - SQL сервер будет первым делом будет стараться размещать страниц таблицы tempdb в оперативной памяти, если там есть достаточно памяти для их размещения (а занимать её там может очень много других процессов и данных SQL сервера), при этом, при нехватке памяти страницы, которые давно не используются - будут удаляться или выгружаться на диск. То есть - новые страницы tempdb изначально могут размещаться только в памяти, не размещаясь на диске (что не справедливо для страниц обычных баз) и выгружаться на диск только при нехватке памяти (но могут сразу размещаться на диске - если SQL сервер, оценив весь предполагаемый объём временной таблицы, поймёт что в памяти их эффективно все не разместить).

И вот, то что мы урежем доступную память, создав RAM диск, лишь увеличит вероятность того, что памяти будет нехватать - и размещение tempdb будет либо сразу либо позже происходить на диске - "в лучшем" случае - на RAM диске, в худшем - на обычном (если в RAM-файловой группе уже тоже нет места). Но в случае недостаточности памяти - это будет приводить и к удалению из неё кешированных страниц основной базы - и повышения вероятности избыточного их повторного чтения с диска.

А ведь ещё есть лог транзакции - он всё время пишется на диск (порциями - чекпойнтами) - интенсивные изменения данных (в т.ч. в tempdb) создают мощный поток записи лога транзакций - если он не будет в памяти - то именно он будет самым медленным звеном у tempdb, но беда в том, что в пиковой нагрузке лог транзакций очень сильно пухнет - и быстрой выходит за раки RAM-диска - скатываясь на запись на обычный диск. А если там же и основные логи баз данных - то "одновременная" интенсивная запись сразу во все файлы на одном диске приведёт к дикими тормозам на оном - и затормозит всю транзакцию обработки данных.
Да, соглашусь - что это важно для опер учета, а для аналитической базы, где строятся отчеты - пухнуть будет только лог транзакций tempdb , но именно тут он чаще всего пухнет очень сильно и, как следствие, выходит за рамки RAM-диска.
А автор статьи вообще не предлагал его размещать на RAM-диске - от чего лог tempdb часто может быть узким звеном, оставаясь на диске, с медленной записью.
Но тут только применение SSD дисков для размещения файлов tempdb даст существенный выигрыш.
25. Glebis 11 29.01.19 16:54 Сейчас в теме
В нашей организации используется RAMDisk "Enterprise" 5.3.2.13. Эта программа бесплатна, больше не развивается, но функционал достаточен. После установки драйвера все настройки происходят в диспетчере устройств.
НЕ на правах рекламы.
32. Glebis 11 29.01.19 17:41 Сейчас в теме
Уважаемые коллеги,
можете ли Вы найти хотя бы одну рекомендацию по настройке инстанса MS SQL с целью ускорения чтения-записи ИМЕННО tempdb, а не данных базы, хранящихся в MDF-LDF (или RAM для более быстрого доступа в MDF-LDF). Перенос на более быстрый диск и распараллеливание на несколько файлов не предлагать.
Лично я не нашёл. Из чего я сделал вывод: чтобы ускорить выполнение, например, отчета со здоровенными временными таблицами (которые целиком находятся в TempDB) никакие настройки инстанса SQL или свойств конкретной БД не помогут, если производительность упирается в скорость работы с TempDB.
36. Darklight 20 29.01.19 18:01 Сейчас в теме
(32)Я ни в коей мере никого не отговариваю от использования RAM Диска для хранения tempdb - сам раньше грёзил этой идеей. Я лишь ратую за то, чтобы люди серьёзно относились к такому решению - грамотно взвешивали все за и против и понимали, что именно это действие реально ускорит хотя бы их личный частный случай.

И я предупреждаю, то что годится для некоторых частных случаев - в общем случае может сделать только хуже! Использование RAM дисков - это не какой-то волшебный буст, дающий прирост производительности из неоткуда - это её перераспределение - если задача будет эффективнее решаться в такой конфигурации - да ради бога - главное, чтобы этот эффект не ударил больно по решению других задач на этом же сервере! RAM DISK - это не панацея - это компромисс, и чаще он будет неудачным!
38. herfis 285 29.01.19 18:55 Сейчас в теме
(36)
RAM DISK - это не панацея - это компромисс, и чаще он будет неудачным!

Да ладно!
Значит, вынос лога tempdb на быстрый носитель - это признанная вами эффективная мера оптимизации производительности, а вынос его же на еще более быстрый носитель (RAM) - это уже потенциально неудачный компромисс. Собака-подозревака моде он.
ben19791010; +1 Ответить
44. Darklight 20 30.01.19 09:44 Сейчас в теме
(38)Конечно - это же разные вещи. Если бы вынос tempdb на RAM диск (вернее не сам вынос а перераспределение оперативной памяти сервера для создания этого RAM диска)) в общем случае не снижал производительность (без учета её потенциального роста от размещения tempdb на RAM диске ) SQL сервера - то это был бы удачный компромисс во всех смыслах. А так - это просто перераспределение ресурсов SQL сервера, которое в общем случае не обязано дать выигрыш - неужели Вы не поняли - я не против выноса tempdb на RAM диск, я против необдуманного выноса, без реальной оценки общего и частного изменения производительности, как моментальной (на тестах), так и статистической за достаточно большой период реальной эксплуатации.

Добавление же диска ssd (или любого другого диска к конфигурации) SQL сервера - не снижает его производительность. Вынос базы tempdb на отдельный (от рабочего) массив дисков, всегда даёт заметный выигрыш в производительности.
47. herfis 285 30.01.19 10:54 Сейчас в теме
(44) Вряд ли я ошибусь, если скажу что тут в основном люди, которым платят деньги не за фулл-тайм исследования. И мне, как и моему работодателю, вполне достаточно будет увидеть значительный прирост производительности на интегральных тестах "с" и "без", чтобы принять решение. Если по-вашему оно будет необдуманным, то и фиг с ним.
Другое дело, что бежать-переворачиваться ставить RAM-диск при отсутствии серьезных проблем с производительностью я бы тоже не стал. Просто не люблю без явной необходимости вводить новые сущности и увеличивать количество потенциальных точек отказа.
Но если, к примеру, есть проблема с производительностью и есть реальный запас по памяти, то вполне можно попробовать RAM-диск вместо того, чтобы решать вопрос с дополнительным приобретением дорогих серверных SSD.
48. Darklight 20 30.01.19 11:31 Сейчас в теме
(47) Если у Вас проблема с производительностью и есть реальный запас по памяти (а я себе это представляю, что у Вас на сервере SQL есть лишние несколько десятков гигабайт ОЗУ), то у Вас скорее всего памяти на сервере действительно черезмерно много - зато остальное железо - полный ахтунг (и, скорее всего, это процессоры) - и именно оно даёт просадку производительности (но для начала надо разбираться в алгоритмах, которые выполняются на этом сервере - и так его просаживают - может дело просто в них). Бывает ещё попросту плохо сконфигурирована работа с дисками, особенно когда используется виртуализация и/или отдельное дисковое хранилище!

И тут лучше начинать именно с анализа монитора показателей функционирования SQL сервера - насколько он использует буфер, как часто попадает в кеш, какая очередь к дискам. Да и вообще - актуализируется ли статистика, проводится ли дефрагментация и реиндексация индексов, сбрасывается ли процедурный кеш и выполняются ли пр. регламенты на SQL сервере.

У SQL сервера есть настройка - сколько памяти он может использовать - попробуйте её уменьшить - и посмотрите как изменится производительность - если не будет сильной просадки - можно поэкспериментировать далее - отдав высвобожденную память под RAM Диск и перенести туда tempdb. Если изменится значительно, то лучше забыть про RAM диск в памяти, её и так SQL серверу не хватает (ну или очень проседает дисковая система).

Ну и как я уже говорил - если tempdb лежит на том же дисковом массиве, что и рабочие базы - то это может очень влиять на падение производительности - тут вынос tempdb в принципе на отдельный дисковый массив может уже дать хороший эффект (будь это RAID HDD или RAM диск - эффект будет).


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

А лично я считаю - что серверные SSD стоят куда дешевле, чем такого же объёма серверная ОЗУ! Если ОЗУ больше чем нужно - ну значит, кто-то явно неэффективно потратил деньги. Хотя, опять таки, лично я считаю, что на SQL сервере лишней памяти не бывает - чем больше отдано скулю, тем лучше и быстрее он работает! Например, если вся БД с лихвой помещается в памяти - то скорость работы с ней заметно возрастает, даже при весьма слабой дисковой системе!
mickey.1cx; +1 Ответить
43. MrWonder 580 30.01.19 09:18 Сейчас в теме
(36) Вообще-то да. Хорошее определение. Это действительно волшебный буст. Спасибо за формулировку.
P.S. Наличие волшебства не отменяет наличия головы.
39. muskul 30.01.19 04:39 Сейчас в теме
Вот бы еще ктото поделился как кэш 1с сервера который тоже пухнет почем зря перенести куданибудь в другое место
40. nyam-nyam 30.01.19 08:50 Сейчас в теме
(39)Как вариант - символьная ссылка. Правда за ней надо следить - сталкивался с ситуацией когда Винда при обновлениях их затирает, т.е. создаёт директорию заново.
42. MrWonder 580 30.01.19 09:16 Сейчас в теме
(39) Перенесите профиль пользователя, под которым работает службы на другой, больший диск.
46. Darklight 20 30.01.19 10:46 Сейчас в теме
(42)Интересно, что же это даст? Хотя да, каталог temp файлов по умолчанию тоже переместится. Но только он.
45. Darklight 20 30.01.19 10:45 Сейчас в теме
(39)Наверное, имелись в виду сеансовые данные кластера сервера 1С Предприятие, которые хранятся в файлах snccntx*.dat?
Тогда они хранятся в каталоге, который указан в строке запуска агента сервера 1С предприятие (ключ "-d") каталог по умолчанию (для windows x64): "c:\Program Files\1cv8\srvinfo\" (ну для 32битного сервера немного другой путь, как и для Linux), там будут подкаталоги самих кластеров вида "reg_<порт кластера>" и уже внутри каталоги вида "snccntx<некий UID>", которые и будут содержать указанные файлы.
Так вот, изменить базовый каталог для всех кластеров можно вышеописанным ключём "-d" строки запуска агента сервера 1С. Но можно так же задать индивидуальные каталоги для каждого кластера (которые "reg_<порт кластера>") - разместив в базовом каталоге файл "swpuser.ini" котором написать строку(и) "registry=<нужный путь к кластеру>", разделяя их секциями (в отдельной строке выше) портов кластеров "<номер порт>:"
(пример
1541:
registry=D:\<MyCluster1541)
самая первая строка (без секции) - будет настройкой для кластеров по умолчанию
более подробно на ИТС

Если же речь идёт о директории c временными файлами - тогда это надо для пользователя, под которым выполняются процессы кластера(ов), настраивать в реестре/конфиг файле (для Linux) (ну или настройках ОС)
Кстати, для процессов кластеров можно (и это рекомендуется) указывать своего отдельного пользователя(ей) - тогда и временные каталоги для них можно отдельные настроить (при необходимости) - делается это в том же файле "swpuser.ini" - строки
user=<имя пользователя для rphost
password=<пароль пользователя для rphost>
rmngr_user=<имя пользователя для rmngr>
rmngr_pass=<пароль пользователя для rmngr>

по вышеупомянутой ссылке на ИТС есть пример!

ещё вот тут гляньте у Гилёва


P.S.
Напомню, что ещё за управление сеансовыми данными в кластере серверов 1С Предприятие отвечает "Сервис сеансовых данных" (выполняется внутри процесса - менеджера кластера - может быть отдельный процесс - если в настройках включено создавать отдельный менеджер для каждого сервиса). Так вот - его можно перенести (или он может автоматически переноситься - если это будет разрешено - а по умолчанию это так) между разным рабочими серверами кластера 1С. Это надо учитывать - так как на разных рабочих серверах настройки каталогов задаются ОТДЕЛЬНО! А при наличии нескольких центральных рабочих серверов (уровень отказоустойчивости выше 1) - сеансовые данные ещё и будут между ними постоянно реплицироваться!

БОЛЕЕ ТОГО - Вы можете выделить отдельный рабочий сервер в кластере, например, только под хранение сеансовых данных (это не требует отдельной лицензии на сервер 1С) - и хранить их вообще на отдельном сервере! Делается это через механизм "назначения функциональности" на рабочих серверах кластера.
Но надо лишь помнить - что если рабочие процессы кластера будут на одном рабочем сервере - а сеансовые данные на другом - при доступе к ним они постоянно будут передаваться по сети!
mivari; WellMaster; mickey.1cx; Rusmus; +4 Ответить
54. A_Max 17 31.01.19 13:46 Сейчас в теме
(45) Ещё вариант. Если не хочется переносить весь срвинфо, то можно использовать hard/soft ссылки конкретных каталогов.
53. WellMaster 99 30.01.19 17:10 Сейчас в теме
(39) Есть такая возможность. Прописывается в параметрах запуска в реестре службы.
50. nvv1970 30.01.19 15:25 Сейчас в теме
Единственной авторитетной статьей по дискам для меня осталась вот эта https://habr.com/ru/post/414269/
Прочтите все. Особенно изучите табличку с задержками на файлах. Сравните со своими.

Автору - зачет, но тестов RAM vs M2sams970PRO не хватает.
51. herfis 285 30.01.19 15:43 Сейчас в теме
(50) Суперская статья, полная суперских ссылок! Сенк.
52. MrWonder 580 30.01.19 15:45 Сейчас в теме
(50) Спасибо. Но мой домашний m2.960pro пока не вырос до 970 (((
55. viptextil1 16 01.02.19 08:43 Сейчас в теме
На мой взгляд - спорное предложение. Дело в том, что сейчас все часто используемые области данных и так кэшируются в памяти. Создавая рамдиск - фрагментируете ресурсы (память) и уменьшаете объем кэша, что может отрицательно сказываться на производительности.
56. user751351 01.02.19 09:13 Сейчас в теме
и никто почему-то не говорит, что работа tempdb с несколькими файлами распределяется равномерно на все файлы, причем в % отношении размера конкретного файла tempdb к общему размеру базы. т.е. если файлы 10G в RAM и 90G на обычном диске, то и использоваться будет 10% и 90% соответственно от запрашиваемого объема на ОДНОЙ задаче!!! не делайте так! и это никак не связано с параллелилизмом, который в большинстве случаев приводит к замедлению на системах с высокой нагрузкой.
57. ogidni 01.02.19 10:15 Сейчас в теме
Автору спасибо и лайк, не смотря на радикальное решение.
Хотелось бы узнать что будет если выдернуть сервер из розетки?
Не уйдет ли MS SQL в защищенный режим?

На дорогих серверных решениях эта задача решается установкой рейд массива с 12Gb кеш памяти и отложной записью данных.
58. MrWonder 580 01.02.19 10:21 Сейчас в теме
(57) TempDB пересоздаётся с каждый запуском 1С. Никуда SQL не уйдёт. Я хотел ещё написать статью о продуктивной базы в RAM-диске (которая не сломается при выключении из розетки), да вот теперь думаю, а нужно ли...
59. ogidni 01.02.19 10:51 Сейчас в теме
(58) Я давно ушел в Linux. Переносил tempdb PostgreSQL на Память видеокарты 1080ti 11Gb (ddr5x). Все норм работает.
год работала потом начал появляться синий экран. Оказалось Видюха сдохла.
Сдал ее по гарантии вернул все взад на SSD. Начало все тупить
MrWonder; +1 Ответить
60. MrWonder 580 01.02.19 11:05 Сейчас в теме
(59) Очень интересный опыт. Раскройте тему подробней, пожалуйста.
62. ogidni 01.02.19 11:54 Сейчас в теме
(60)Как видюха придет с ремонта. Напишу.
MrWonder; +1 Ответить
67. DonAlPatino 133 05.02.19 11:25 Сейчас в теме
(59) А можно подробнее? Это такая специфика Линукс, что можно видеопамять как часть файловой системы использовать? И, правильно ли я понимаю, что это сделано это не на серверной материнке/платформе?
61. herfis 285 01.02.19 11:32 Сейчас в теме
63. AntonSm 26 01.02.19 14:08 Сейчас в теме
(58) Нужно. Очень интересно.
64. ogidni 01.02.19 17:35 Сейчас в теме
(58)В 2007 году я покупал Gigabyte i-RAM. Очень пожалел. Так что выкладывайте
Прикрепленные файлы:
65. viptextil1 16 04.02.19 08:33 Сейчас в теме
(64)Это работало, когда памяти не хватало на 32 битных системах. Сейчас лучше и дешевле поставить больше памяти.
66. ogidni 04.02.19 09:50 Сейчас в теме
(65)
ботало, когда памяти не хватало на 32 битных системах. Сейчас лучше и дешевле поставить больше памяти.

там смысл был в батарейке. При которой данные при вырубании компа не терялись
68. user612295_death4321 06.02.19 07:07 Сейчас в теме
А какие диски у автора в данный момент стоят, что прирост производительности на операции закрытие месяца аж в 2 раза лучше стало ?
Интересно, сильно заметна разница если темп дб хранится на рам диске или схд на nvme дисках.
76. PerlAmutor 47 22.04.19 18:47 Сейчас в теме
(0)
P.S. Лишь внедрением RAM TempDB мы смогли ускорить закрытие месяца в ERP в два раза.


Оптимизировав типовой запрос ERP, который выполняется при закрытии месяца, мне удалось увеличить скорость закрытия в 4 раза.
Время закрытия было одинаково для рабочего сервера и тестового (с RAM-диском), чуть ли не минута в минуту.
77. MrWonder 580 22.04.19 22:22 Сейчас в теме
(76) Обязательно напишите об этом подробнее.
78. d4rkmesa 24.04.19 08:22 Сейчас в теме
(76) Хе-хе, ну если уж меряться, от обскакать 1С с ее нативной реализацией решения СЛУ в новой платформе, которое по слухам увелит скорость закрытия на порядок, вряд ли удастся.
79. PerlAmutor 47 24.04.19 18:50 Сейчас в теме
(78) СЛУ - лишь часть одного этапа - расчета себестоимости. А в закрытии этапов много разных. Тот запрос, который я оптимизировал к решению СЛУ не относится. Кстати возможно у многих этот запрос отрабатывает как и должен и проблемы нет. Но у меня картина и на продакшене и на тестовом сервере и на разных версиях платформы и на разных версиях SQL серверов - стабильно плохая была. Я смотрел последние версии ERP, там этот запрос видоизменился, но основная причина его долгого выполнения так и не была устранена разработчиками. Опять же я не говорю, что он медленно выполняется у всех поголовно. Все зависит от объемов регистра.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Программист/Cтарший программист 1С
Москва
зарплата от 100 000 руб. до 250 000 руб.
Полный день

Программист 1С
Калининград
зарплата от 60 000 руб. до 80 000 руб.
Полный день

Руководитель проектов 1С
Санкт-Петербург
Полный день

Программист 1С
Новосибирск
зарплата от 80 000 руб. до 150 000 руб.
Полный день

Программист 1С
Красноярск
зарплата от 50 000 руб.
По совместительству