Статьи, в которых предлагалось выносить tempDB в ram-диск уже были на Infostart (//infostart.ru/public/330256/).
В данной мне хотелось рассказать более подробно об опыте подобной настройки на системах, работающих 24/7.
Для начала посмотрим на метрики, какой же прирост производительности может быть получен от использования RAM-диска.
Безусловно, данный тест является синтетическим и не отражает реальный профит(который будет ниже), но разница в цифрах является весьма показательной.
При использовании RAM-диска у нас всегда будет возникать одна проблема — что будет, если размер tempDB выйдет за пределы RAM-диска?
Эта проблема решается весьма просто — MSSQL позволяет создавать дополнительные файлы данных и логов, в том числе для tempDB.
Таким образом общие рекомендации сводятся к следующему:
Первый файл данных tempDB — на RAM-диске, фиксированного размера (я ставлю 75%) от размера RAM-диске. Отключен autogrowth.
Первый файл логов tempDB — на RAM-диске, фиксированного размера (я ставлю 25%) от размера RAM-диске. Отключен autogrowth.
Второй файл данных tempDB — на обычном диске, начальный размер 8 Mb. Включен autogrowth.
Второй файл логов tempDB — на обычном диске, начальный размер 8 Mb. Включен autogrowth.
Таким образом, при росте размера tempDB и выходе его "из берегов" RAM-диска он просто расширится на медленные диски.
Чтобы сжать дополнительные файлы БД, если tempDB выросла в их размеры, настраивается простенький план обслуживания на ночь:
USE [tempdb]
DBCC SHRINKFILE (N'tempdev_ext', EMPTYFILE);
DBCC SHRINKFILE (N'tempdev_ext', TRUNCATEONLY)
DBCC SHRINKFILE (N'templog_ext', EMPTYFILE);
DBCC SHRINKFILE (N'templog_ext', TRUNCATEONLY);
P.S. Лишь внедрением RAM TempDB мы смогли ускорить закрытие месяца в ERP в два раза.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Эх! А я-то думал, что в статье будет описано, как именно сделать на сервере RAM-диск.
Какой понадёжнее, какой подешевле и т.п.
Ответьте, пожалуйста, с помощью какой программы вы делали RAM-диск?
(2) imDisk Toolkit — как пример из статьи.
(2)
Можете найти старую бесплатную версию
(1) Ниже написал, каким диском пользуюсь.
Вопросы установки и настройки нужно рассмотреть?
(5) Да не. Разобраться с установкой там легко.
Просто пишу свой отзыв о статье.
Я рассчитывал на сравнительный анализ ПО для RAM-дисков, а статья оказалась о другом. 🙂
Плюсанул за разнесение по файлам для решения проблемы переполнения.
Вроде банальная штука, но почему-то никогда в голову не приходила. Правда и вопрос этот всерьез не рассматривал.
(4)
«Free for non-commercial use»
(8) а теперь 2 тыщи домашняя версия и чуть больше 3к — коммерческая. Для организации копейки, так-то.
(7) А знаете, сколько рекомендуется создавать файлов tempdb?
Ответ по ссылке —
(4) Интерес скорее вызывает не столько цена, сколько опыт эксплуатации.
У вас это на рабочей базе/базах?
И нормально работает?
MS SQL сам кэширует в памяти все что нужно без всяких RAM-дисков. Без тестов производительности статья ни о чем. Разбивать TempDB на несколько файлов — описано в настройках MS SQL от 1С, вероятно закрытие месяца от этого и ускорилось.
(11) не нормально, а великолепно.
(12) Спасибо за Ваш ответ. Держите меня в курсе.
(9) Хм… И за счет чего ожидается прирост, если файлики рядом лежат?
Да и выставлять степень параллелизма в единицу — тоже спорный совет. Это радикально замедляет формирование тяжелых отчетов.
ЗЫ. Почитал про разбиение tempdb — это скорее прикрытие возможного узкого места (при большом количестве конфликтов при мультипоточном доступе к файлу), чем кнопка «турбо». Т.е. может и не иметь никакого эффекта.
(15) Правильно ли я понял Ваш вопрос — за счёт чего возникает прирост производительности после перемещения tempDB в RAM. Верно?
(9) Конечно знаю. Но в данной ситуации рекомендация разбивать неприменима. Нужно ли объяснить, почему?
Было такое, как по изначальной статье, даже базы выносили, но потом все равно на ssd перешли.
Тем более в новых скулях есть настройки Buffer Pool Extension.
Как вы после перезагрузки сервера действуете или MSSQL в отложенном запуске?
(18) В отложенном. SoftPerfect Ramdisk умеет после перезагрузки восстанавливаться. Даже с содержимым.
За рекламу бы с них, поправиться, для бывшего регента ))
(16) Нет. Вопрос касался разделения tempdb на несколько файлов на одном и том же диске. Вопрос был не к вам.
Но если знаете точный ответ — буду благодарен. И актуальна ли эта рекомендация для RAID 5 и выше.
(20) Спасибо за Ваш развёрнутый комментарий. Он, пожалуй, размером больше моей инструкции (я не считаю это статьёй).
И писать развёрнутое исследование о том, как это выглядит и работает с разных сторон я пока не готов — времени на другие задачи остаётся мало.
Целью было лишь дать технику, которая работает и хорошо себя показала.
(22) вам об этом и говорят, что нужно следовать правилу паретто — 80% думаем, 20% делаем. ваша статья — призыв не думать, а сразу делать рам диск, показала же хорошо …
(20)(23) Тут дело такое… Якобы да — сиквел сам должен грамотно справляться и что-то можно выжать грамотными настройками. И сами мелкомягкие относительно применения рам-дисков отзываются с осторожностью. Если не с осуждением. Мол двойное кэширование получается и все такое… Но вот сколько народ пробует — на практике получает неизменно отличные результаты 🙂 Можно пытаться списывать на криворукость народа, но не припоминаю ни одного случая чтобы какой-нибудь эксперт попробовал и сказал — фигня эти ваши рам-диски, и без них можно настроить не хуже.
В нашей организации используется RAMDisk «Enterprise» 5.3.2.13. Эта программа бесплатна, больше не развивается, но функционал достаточен. После установки драйвера все настройки происходят в диспетчере устройств.
НЕ на правах рекламы.
(20)Как вариант объяснения ускорения — SQL не хватает памяти на работу баз и отчёты одновременно. В этот момент он может не дать приоритет отчёту (тяжелый и долгий — скину ка я его на tempdb 🙂 ). Вот у ускорение получается — в RAM диске всяко быстрее будет чем на HDD. Хотя накладные расходы конечно огромные получаются. Но это уже дело админа решать какой вариант его больше устроит.
(12) Я не являюсь экспертом по SQL, но насколько мне известно есть куча настроек (хеширование, статистика), которые отвечают за скорость работы с данными, ХРАНЯЩИМИСЯ НЕПОСРЕДСТВЕННО в базе (файле MDF). Но эти настройки (ИМХО) не ускоряют работы с файлами TempDB, которые (источник этой информации указать не могу) не планировались в роли оперативного хранилище здоровенных массивов информации, как сейчас их использует платформа 1С.
(24)Вот поэтому я и ратую за то, чтобы тут нормальную статью написали — с анализом, а не не просто «стало быстрее» — а если бы эксперт разбралася с тем что было и с тем что стало — может оно уже и не так уж офигенно вышло в результате, тем более для общего случая! А сейчас эта «статья» выглядит как ничем реальным не подкреплённый призыв «все на RAM диск» — это панацея для ускорения производительности в пиковой нагрузке. А из всех тестов — приведены два скриншота бенчмарка скоростей работы…. ээээ…. физического и RAM дисков — «две сферические лошади в вакууме меряются копытами»! Тут даже ни циферки о скорости изменения работы SQL Server — сдаётся автор всё мерил на глаз — по своим ощущениям! Тем более нет писаний конфигураций до и после! Чтобы понять за счёт чего был прирост!
(26)Поэтому чтобы делать RAM tempdb нужно реально понимать что это даст, какой будет выигрыш, в каких случаях, а в каких наоборот — будет просадка производительности! Нужны тесты, нужна статистика долговременной эксплуатации! нужны описания как всё это протестировать самостоятельно — чтобы те, кого это заинтересует сначала тоже провели тесты у себя, сравнили результаты, и уже потом принимал решение — что лучше!
Но, на мой взгляд, лучше начинать с вынесения tempdb на отдельный SSD диск(и). Если эффекта не достаточно — думать о вынесении лога транзакций tempdb в RAM. А вот, если эффекта от переноса tempdb на SSD вообще крайне недостаточно — уверен, что и вынос его на RAM диск не приведёт к заметному улучшению — а скорее даже к ухудшению — т.к. тут явно узкое место не в tempdb.
А вот эта фраза мне вообще не понятна! Не могу представить как SQL Server скидывает «отчет» (о котором понятии он вообще не знает) на tempdb. В tempdb создаются временные таблицы, результаты временных вычислений при выполнении физических операций SQL Server над данными, там хранятся кешированные результаты выполнения запросов, там хранятся данные незавершённых транзакций. Сам SQL Server туда ничего не скидывает, когда ему не хватает ресурсов.
SQL Server старается держать данные tempdb в памяти — но когда её не хватает — неиспользуемые кеши удаляются, а ещё занятые временные таблицы свопятся в файлы данных tempdb. Причём, так как автор разбивает файл tempdb на части, не факт, что это выгрузка на диск, пройдёт именно на RAM-диск. Никаких возможностей управлять тем, что важно хранить в памяти, а что можно и на физ диск сбросить — вообще нет! Это всё дело случая….
А, вот, кешированные страницы данных, в tempdb насколько я знаю, не хранятся — для этого используется буфер SQL Server — и если памяти для SQL свервера выделено мало — то значит и этот буфер будет небольшой — значит и за страницами данных SQL сервер будет чаще лазить на диск…. на физический диск с данными!
Конечно, если изначально выстраивать запросы так, чтобы использовать временные таблицы по максимуму — то от их размещения в RAM диске будет какой-то толк — но это реально нужно всю логику работы с данными под это адаптировать — 1С Предприятие 8 и её конфигурации так не умеют!
(23) Спасибо за Ваш отзыв. У меня, безусловно, есть некоторый бэкграунд в описываемой области.
Если Вам это не подходит — не используйте. Если хотите проводить тесты — проводите.
(28) Я Вам лично ничего не обещал. Если не оправдал Ваши ожидания, то дело лишь в Ваших ожиданиях.
Уважаемые коллеги,
можете ли Вы найти хотя бы одну рекомендацию по настройке инстанса MS SQL с целью ускорения чтения-записи ИМЕННО tempdb, а не данных базы, хранящихся в MDF-LDF (или RAM для более быстрого доступа в MDF-LDF). Перенос на более быстрый диск и распараллеливание на несколько файлов не предлагать.
Лично я не нашёл. Из чего я сделал вывод: чтобы ускорить выполнение, например, отчета со здоровенными временными таблицами (которые целиком находятся в TempDB) никакие настройки инстанса SQL или свойств конкретной БД не помогут, если производительность упирается в скорость работы с TempDB.
(29) Павел, если Вам нужны тесты и статистика долговременной эксплуатации, Вы знаете что делать.
Почему Вы требуете их от меня? Я всего лишь скромный автор небольшой инструкции, не способный на удовлетворение Ваших желаний.
Ваши взгляды очень ценны. Спасибо Вам.
(33)Ничего от Вас не требую!
(34) Спасибо. В качестве благодарности примите показатели для TempDB в Ram и не в Ram.
(32)Я ни в коей мере никого не отговариваю от использования RAM Диска для хранения tempdb — сам раньше грёзил этой идеей. Я лишь ратую за то, чтобы люди серьёзно относились к такому решению — грамотно взвешивали все за и против и понимали, что именно это действие реально ускорит хотя бы их личный частный случай.
И я предупреждаю, то что годится для некоторых частных случаев — в общем случае может сделать только хуже! Использование RAM дисков — это не какой-то волшебный буст, дающий прирост производительности из неоткуда — это её перераспределение — если задача будет эффективнее решаться в такой конфигурации — да ради бога — главное, чтобы этот эффект не ударил больно по решению других задач на этом же сервере! RAM DISK — это не панацея — это компромисс, и чаще он будет неудачным!
(35)Вот это уже полезнее, но ненамного, коли не указаны условия, при которых собрана эта статистика. Без них — она лишь говори о том, что какая-то задача(и) чаще обращалась к файлу tempdb на диске T (RAM), чем к физическому размещению. Но это не показатель. Понятно, что к примеру, когда объём данных хранящихся tempdb априори укладывается в эту часть tempdb, размещаемую на быстром диске — sQL Server будет их размещать именно там. Но что будет, когда обороты данных будут стремительно расти и понадобится более интенсивно задействовать физ часть. Вот, например, сделайте закрытие месяца с настройками так, чтобы физ часть выросла в 2 раза больше, чем выделенная RAM часть (что покажет наличие действительно большой оборачиваемости виртуальных таблиц) — вот и посмотрим, насколько статистика обращения к RAM диску будет превосходить обращения к физ диску tempdb
А ещё, для сравнения — нужно повести ту же операцию с теми же данными (после рестарта SQL сервера для чистоты), но уже только с задействованным тем же tembdb. Ну и в идеале всё это ещё закрепить графиками использования буфера sql, числа попаданий в кеш, и аналогичной статикой обращения к данным БД — чтобы показать, что там не произошло серьёзной просадки.
ну и конечно же сделать численный замер — сколько операция выполнялась с RAM диском, и сколько без него. да и указать, сколько памяти осталось SQL серверу.
(36)
Да ладно!
Значит, вынос лога tempdb на быстрый носитель — это признанная вами эффективная мера оптимизации производительности, а вынос его же на еще более быстрый носитель (RAM) — это уже потенциально неудачный компромисс. Собака-подозревака моде он.
Вот бы еще ктото поделился как кэш 1с сервера который тоже пухнет почем зря перенести куданибудь в другое место
(39)Как вариант — символьная ссылка. Правда за ней надо следить — сталкивался с ситуацией когда Винда при обновлениях их затирает, т.е. создаёт директорию заново.
(29)Я тоже за научный подход. Но Инфостарт не научное издание, и требовать от каждой статьи научного подхода со статистически значимыми результатами слегка наивно. Автор поделился своим решением в своей совершенно конкретной ситуации и нигде в статье не гарантировал что его подход является универсальным.
(39) Перенесите профиль пользователя, под которым работает службы на другой, больший диск.
(36) Вообще-то да. Хорошее определение. Это действительно волшебный буст. Спасибо за формулировку.
P.S. Наличие волшебства не отменяет наличия головы.
(38)Конечно — это же разные вещи. Если бы вынос tempdb на RAM диск (вернее не сам вынос а перераспределение оперативной памяти сервера для создания этого RAM диска)) в общем случае не снижал производительность (без учета её потенциального роста от размещения tempdb на RAM диске ) SQL сервера — то это был бы удачный компромисс во всех смыслах. А так — это просто перераспределение ресурсов SQL сервера, которое в общем случае не обязано дать выигрыш — неужели Вы не поняли — я не против выноса tempdb на RAM диск, я против необдуманного выноса, без реальной оценки общего и частного изменения производительности, как моментальной (на тестах), так и статистической за достаточно большой период реальной эксплуатации.
Добавление же диска ssd (или любого другого диска к конфигурации) SQL сервера — не снижает его производительность. Вынос базы tempdb на отдельный (от рабочего) массив дисков, всегда даёт заметный выигрыш в производительности.
(42)Интересно, что же это даст? Хотя да, каталог temp файлов по умолчанию тоже переместится. Но только он.
(44) Вряд ли я ошибусь, если скажу что тут в основном люди, которым платят деньги не за фулл-тайм исследования. И мне, как и моему работодателю, вполне достаточно будет увидеть значительный прирост производительности на интегральных тестах «с» и «без», чтобы принять решение. Если по-вашему оно будет необдуманным, то и фиг с ним.
Другое дело, что бежать-переворачиваться ставить RAM-диск при отсутствии серьезных проблем с производительностью я бы тоже не стал. Просто не люблю без явной необходимости вводить новые сущности и увеличивать количество потенциальных точек отказа.
Но если, к примеру, есть проблема с производительностью и есть реальный запас по памяти, то вполне можно попробовать RAM-диск вместо того, чтобы решать вопрос с дополнительным приобретением дорогих серверных SSD.
(47) Если у Вас проблема с производительностью и есть реальный запас по памяти (а я себе это представляю, что у Вас на сервере SQL есть лишние несколько десятков гигабайт ОЗУ), то у Вас скорее всего памяти на сервере действительно черезмерно много — зато остальное железо — полный ахтунг (и, скорее всего, это процессоры) — и именно оно даёт просадку производительности (но для начала надо разбираться в алгоритмах, которые выполняются на этом сервере — и так его просаживают — может дело просто в них). Бывает ещё попросту плохо сконфигурирована работа с дисками, особенно когда используется виртуализация и/или отдельное дисковое хранилище!
И тут лучше начинать именно с анализа монитора показателей функционирования SQL сервера — насколько он использует буфер, как часто попадает в кеш, какая очередь к дискам. Да и вообще — актуализируется ли статистика, проводится ли дефрагментация и реиндексация индексов, сбрасывается ли процедурный кеш и выполняются ли пр. регламенты на SQL сервере.
У SQL сервера есть настройка — сколько памяти он может использовать — попробуйте её уменьшить — и посмотрите как изменится производительность — если не будет сильной просадки — можно поэкспериментировать далее — отдав высвобожденную память под RAM Диск и перенести туда tempdb. Если изменится значительно, то лучше забыть про RAM диск в памяти, её и так SQL серверу не хватает (ну или очень проседает дисковая система).
Ну и как я уже говорил — если tempdb лежит на том же дисковом массиве, что и рабочие базы — то это может очень влиять на падение производительности — тут вынос tempdb в принципе на отдельный дисковый массив может уже дать хороший эффект (будь это RAID HDD или RAM диск — эффект будет).
А насчёт того, что работодателю нужен эффект а не анализ — это очень плохо для задач оптимизации — так как в погоне за мимолётным эффектом можно не заметить как проблемы подкатят с другой стороны!
А лично я считаю — что серверные SSD стоят куда дешевле, чем такого же объёма серверная ОЗУ! Если ОЗУ больше чем нужно — ну значит, кто-то явно неэффективно потратил деньги. Хотя, опять таки, лично я считаю, что на SQL сервере лишней памяти не бывает — чем больше отдано скулю, тем лучше и быстрее он работает! Например, если вся БД с лихвой помещается в памяти — то скорость работы с ней заметно возрастает, даже при весьма слабой дисковой системе!
(9) Не правильно давать ссылку на «перепосты», а не на первоисточник.
Плохо, что для 1С-ников истина по SQL на сайте 1С, а не на MSDN ((((
Единственной авторитетной статьей по дискам для меня осталась вот эта
Прочтите все. Особенно изучите табличку с задержками на файлах. Сравните со своими.
Автору — зачет, но тестов RAM vs M2sams970PRO не хватает.
(50) Суперская статья, полная суперских ссылок! Сенк.
(50) Спасибо. Но мой домашний m2.960pro пока не вырос до 970 (((
(39) Есть такая возможность. Прописывается в параметрах запуска в реестре службы.
(45) Ещё вариант. Если не хочется переносить весь срвинфо, то можно использовать hard/soft ссылки конкретных каталогов.
На мой взгляд — спорное предложение. Дело в том, что сейчас все часто используемые области данных и так кэшируются в памяти. Создавая рамдиск — фрагментируете ресурсы (память) и уменьшаете объем кэша, что может отрицательно сказываться на производительности.
и никто почему-то не говорит, что работа tempdb с несколькими файлами распределяется равномерно на все файлы, причем в % отношении размера конкретного файла tempdb к общему размеру базы. т.е. если файлы 10G в RAM и 90G на обычном диске, то и использоваться будет 10% и 90% соответственно от запрашиваемого объема на ОДНОЙ задаче!!! не делайте так! и это никак не связано с параллелилизмом, который в большинстве случаев приводит к замедлению на системах с высокой нагрузкой.
Автору спасибо и лайк, не смотря на радикальное решение.
Хотелось бы узнать что будет если выдернуть сервер из розетки?
Не уйдет ли MS SQL в защищенный режим?
На дорогих серверных решениях эта задача решается установкой рейд массива с 12Gb кеш памяти и отложной записью данных.
(57) TempDB пересоздаётся с каждый запуском 1С. Никуда SQL не уйдёт. Я хотел ещё написать статью о продуктивной базы в RAM-диске (которая не сломается при выключении из розетки), да вот теперь думаю, а нужно ли…
(58) Я давно ушел в Linux. Переносил tempdb PostgreSQL на Память видеокарты 1080ti 11Gb (ddr5x). Все норм работает.
год работала потом начал появляться синий экран. Оказалось Видюха сдохла.
Сдал ее по гарантии вернул все взад на SSD. Начало все тупить
(59) Очень интересный опыт. Раскройте тему подробней, пожалуйста.
(58) Нужно.
(60)Как видюха придет с ремонта. Напишу.
(58) Нужно. Очень интересно.
(58)В 2007 году я покупал Gigabyte i-RAM. Очень пожалел. Так что выкладывайте
(64)Это работало, когда памяти не хватало на 32 битных системах. Сейчас лучше и дешевле поставить больше памяти.
(65)
там смысл был в батарейке. При которой данные при вырубании компа не терялись
(59) А можно подробнее? Это такая специфика Линукс, что можно видеопамять как часть файловой системы использовать? И, правильно ли я понимаю, что это сделано это не на серверной материнке/платформе?
А какие диски у автора в данный момент стоят, что прирост производительности на операции закрытие месяца аж в 2 раза лучше стало ?
Интересно, сильно заметна разница если темп дб хранится на рам диске или схд на nvme дисках.
(12)
MS SQL сам кэширует в памяти все что нужно без всяких RAM-дисков.
MS SQL при построении плана запроса рассчитывает необходимое количество памяти и, если ошибается, то начинает задействовать tempdb. Это легко увидеть, если в профайлере получить планы запросов. Там, где стоит желтый восклицательный знак, там внутри как раз и пишет, что был задействован tempdb. Часто такое происходит на процедурах сортировки.
(20) Ну блин, столько текста и в конце противоречие самому себе.. тезис:
опровергается своим же опытом:
Коллега, а где же исследование, где доказательства, что на отдельном массиве будет быстрее? где описание экономического выигрыша?
(70)Где противоречия?
Я написал что tempdb на отдельном массиве будет, с вероятностью близкой к 100%, заметно быстрее, чем на том же массиве, где и основные базы. И не важно — какой это будет массив — sdd, hdd, ram или ещё какой. Главное — отдельный! Для RAID ещё важно указать, что это отдельный лун.
Вот насколько будет быстрее — зависит от очень большого числа факторов. Но, чаще всего, сели был 1 физический HDD-массив, а станет 2(3) физических HDD массива (основной, tempdb data, tempdb log — tempdb разделять на разные физические диски имеет смысл только для HDD массива)- скорость действительно вырастет весьма заметно, особенно в период интенсивного формирования отчётности, и проведения регламентных операций. А, вот, вынос на RAM диск — заметного прироста производительности может и не дать (а в ряде случаев — даже привести к её снижению).
Отдельно замечу, что если всё лежало на SSD массиве — то вынос tempdb на отдельный SSD массив тоже может не дать заметного прироста производительности.
Отдельно замечу, то при испоользовании виртуализованных массивов (на СХД или на хостах виртуализации) — есть свои нюансы правильной настройки доступа к «массиву» — если настроить неправильно — то такой вынос tempdb на отдельный массив тоже может не дать прироста, и, даже наоборот, привести к снижению производительности.
Ну а если Вы ещё и баз для отчётов вынесите отдельно от базы для проводок, и настроите синхронизацию — так прирост будет ещё выше, ЗНАЧИТЕЛЬНО ВЫШЕ!
Это не моя статья. Я лишь написал своё предложение исходя из имеющегося у меня опыта.
И я всего-лишь намекнул, что надо экспериментировать с разными конфигурациями в каждом конкретном случае эксплуатации — чтобы понять, что именно для Вас будет наиболее эффективно. А не тупо следовать советам того или иного советчика — типа «делай вот как я и будет тебе счастье»!
(71) явные противоречия, сначала топим против RAM, приводя доводы, что «все таблицы и так в памяти», а потом случай из практики — перенесите на другой диск и будет быстрее. Но если таблицы в памяти, то требования к диску и так минимальны и эффект должен быть очень слабым.
собственно автор сделал тоже самое.
(72)»все таблицы и так в памяти» — где я такое говорил? Если бы все таблицы были в памяти то да, скорость чтения с диска была бы не важна (но вот скорость записи на диск, по-прежнему была бы важна). Но такая ситуация бывает не часто, даже для tempdb
Я лишь говорил, что таблицы tempdb MS SQL сервер старается держать в памяти, но только если для них там достаточно памяти и она не требуется для других таблиц. Вот тут-то вся загвоздка — память-то не бесконечна — и на что её выделять — на хранение всей tempdb (или её части — но это отдельная тема) в памяти (причём, порой, сразу нескольких экземпляров одних и тех же страниц данных — дублирование расхода ресурсов), и пожертвовать хранением там страниц данных других таблиц (и даже для tempdb заставлять SQL сервер гонять их туда-сюда через шину драйвера RAM диска); или на дать SQL серверу самому решать — что они будет хранить в памяти (и без лишнего дублирования), не жертвуя хранением страниц других таблиц, но получить большее проседание на операциях течение/записи данных на физический диск — когда памяти-таки не будет хватать.
А вынос tempdb на отдельный физически носитель (даже на HDD) — экономически дешевле, чем наращивание памяти на SQL сервере — и начинать стоит именно с этого — чаще всего уже этого будет вполне достаточно, особенно если это будет SSD диск. И дать SQL серверу самому управлять памятью — ему виднее, что что у него востребовано, а что нет.
Но опять-таки, я не утверждаю, что эта рекомендация верна для всех и всегда — тут нужно экспериментировать и сравнивать — у каждого свои особые условия эксплуатации СУБД!
Но я не делал из своего предложения статью! Я просто контраргументировал, причём, ни разу не говорил, что выкладки автора статьи — ложные. Просто действия автора требуют глубокого понимания того, что будет в итоге — обязательного длительного тестирования. Вот это автор и не сделал (не изложил в статье; а я статью, со «своей идеей» здесь не публиковал).
(73) так вот же прямая цитата в (20):
в общем и в целом действительно можно провести большое исследование и проверить влияние кучи параметров и в ряде условий RAM будет полезен, в ряде вреден, всё индивидуально.
И если Вас статья подтолкнула на такую идею исследования, так welcome — сообщество спасибо скажет.
(74)Если очень внимательно прочитаете, что цитируете, то поймёте, что там написано «с приоритетом хранения в оперативной памяти (если её конечно достаточно)». И это самое важное, исключительно по моей точке зрения — SQL сервер будет первым делом будет стараться размещать страниц таблицы tempdb в оперативной памяти, если там есть достаточно памяти для их размещения (а занимать её там может очень много других процессов и данных SQL сервера), при этом, при нехватке памяти страницы, которые давно не используются — будут удаляться или выгружаться на диск. То есть — новые страницы tempdb изначально могут размещаться только в памяти, не размещаясь на диске (что не справедливо для страниц обычных баз) и выгружаться на диск только при нехватке памяти (но могут сразу размещаться на диске — если SQL сервер, оценив весь предполагаемый объём временной таблицы, поймёт что в памяти их эффективно все не разместить).
И вот, то что мы урежем доступную память, создав RAM диск, лишь увеличит вероятность того, что памяти будет нехватать — и размещение tempdb будет либо сразу либо позже происходить на диске — «в лучшем» случае — на RAM диске, в худшем — на обычном (если в RAM-файловой группе уже тоже нет места). Но в случае недостаточности памяти — это будет приводить и к удалению из неё кешированных страниц основной базы — и повышения вероятности избыточного их повторного чтения с диска.
А ведь ещё есть лог транзакции — он всё время пишется на диск (порциями — чекпойнтами) — интенсивные изменения данных (в т.ч. в tempdb) создают мощный поток записи лога транзакций — если он не будет в памяти — то именно он будет самым медленным звеном у tempdb, но беда в том, что в пиковой нагрузке лог транзакций очень сильно пухнет — и быстрой выходит за раки RAM-диска — скатываясь на запись на обычный диск. А если там же и основные логи баз данных — то «одновременная» интенсивная запись сразу во все файлы на одном диске приведёт к дикими тормозам на оном — и затормозит всю транзакцию обработки данных.
Да, соглашусь — что это важно для опер учета, а для аналитической базы, где строятся отчеты — пухнуть будет только лог транзакций tempdb , но именно тут он чаще всего пухнет очень сильно и, как следствие, выходит за рамки RAM-диска.
А автор статьи вообще не предлагал его размещать на RAM-диске — от чего лог tempdb часто может быть узким звеном, оставаясь на диске, с медленной записью.
Но тут только применение SSD дисков для размещения файлов tempdb даст существенный выигрыш.
(0)
Оптимизировав типовой запрос ERP, который выполняется при закрытии месяца, мне удалось увеличить скорость закрытия в 4 раза.
Время закрытия было одинаково для рабочего сервера и тестового (с RAM-диском), чуть ли не минута в минуту.
(76) Обязательно напишите об этом подробнее.
(76) Хе-хе, ну если уж меряться, от обскакать 1С с ее нативной реализацией решения СЛУ в новой платформе, которое по слухам увелит скорость закрытия на порядок, вряд ли удастся.
(78) СЛУ — лишь часть одного этапа — расчета себестоимости. А в закрытии этапов много разных. Тот запрос, который я оптимизировал к решению СЛУ не относится. Кстати возможно у многих этот запрос отрабатывает как и должен и проблемы нет. Но у меня картина и на продакшене и на тестовом сервере и на разных версиях платформы и на разных версиях SQL серверов — стабильно плохая была. Я смотрел последние версии ERP, там этот запрос видоизменился, но основная причина его долгого выполнения так и не была устранена разработчиками. Опять же я не говорю, что он медленно выполняется у всех поголовно. Все зависит от объемов регистра.