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

Публикация № 990824

Администрирование - Производительность и оптимизация (HighLoad)

ram tempdb mssql ускорение

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

Статьи, в которых предлагалось выносить tempDB в ram-диск уже были на Infostart (//catalog.its22.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 в два раза.

90

Специальные предложения

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

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


MS SQL при построении плана запроса рассчитывает необходимое количество памяти и, если ошибается, то начинает задействовать tempdb. Это легко увидеть, если в профайлере получить планы запросов. Там, где стоит желтый восклицательный знак, там внутри как раз и пишет, что был задействован tempdb. Часто такое происходит на процедурах сортировки.
AnderWonder; +1 Ответить
18. capitan 1271 29.01.19 12:22 Сейчас в теме
Было такое, как по изначальной статье, даже базы выносили, но потом все равно на ssd перешли.
Тем более в новых скулях есть настройки Buffer Pool Extension.
Как вы после перезагрузки сервера действуете или MSSQL в отложенном запуске?
19. MrWonder 574 29.01.19 12:32 Сейчас в теме
(18) В отложенном. SoftPerfect Ramdisk умеет после перезагрузки восстанавливаться. Даже с содержимым.
За рекламу бы с них, поправиться, для бывшего регента ))
20. Darklight 19 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 у Вас уже пропадёт!
vvp117; GreenDragon; d4rkmesa; akim2040; user1144316; alest; Sanya1984; smallbuk; Dragonim; Rusmus; strrike; lohmatik; CSiER; mickey.1cx; nyam-nyam; mivari; kolya_tlt; MrWonder; AnderWonder; rintik; +20 1 Ответить
22. MrWonder 574 29.01.19 15:42 Сейчас в теме
(20) Спасибо за Ваш развёрнутый комментарий. Он, пожалуй, размером больше моей инструкции (я не считаю это статьёй).
И писать развёрнутое исследование о том, как это выглядит и работает с разных сторон я пока не готов - времени на другие задачи остаётся мало.
Целью было лишь дать технику, которая работает и хорошо себя показала.
23. kolya_tlt 11 29.01.19 16:11 Сейчас в теме
(22) вам об этом и говорят, что нужно следовать правилу паретто - 80% думаем, 20% делаем. ваша статья - призыв не думать, а сразу делать рам диск, показала же хорошо ...
GreenDragon; +1 Ответить
30. MrWonder 574 29.01.19 17:38 Сейчас в теме
(23) Спасибо за Ваш отзыв. У меня, безусловно, есть некоторый бэкграунд в описываемой области.
Если Вам это не подходит - не используйте. Если хотите проводить тесты - проводите.
24. herfis 283 29.01.19 16:48 Сейчас в теме
(20)(23) Тут дело такое... Якобы да - сиквел сам должен грамотно справляться и что-то можно выжать грамотными настройками. И сами мелкомягкие относительно применения рам-дисков отзываются с осторожностью. Если не с осуждением. Мол двойное кэширование получается и все такое... Но вот сколько народ пробует - на практике получает неизменно отличные результаты :) Можно пытаться списывать на криворукость народа, но не припоминаю ни одного случая чтобы какой-нибудь эксперт попробовал и сказал - фигня эти ваши рам-диски, и без них можно настроить не хуже.
28. Darklight 19 29.01.19 17:24 Сейчас в теме
(24)Вот поэтому я и ратую за то, чтобы тут нормальную статью написали - с анализом, а не не просто "стало быстрее" - а если бы эксперт разбралася с тем что было и с тем что стало - может оно уже и не так уж офигенно вышло в результате, тем более для общего случая! А сейчас эта "статья" выглядит как ничем реальным не подкреплённый призыв "все на RAM диск" - это панацея для ускорения производительности в пиковой нагрузке. А из всех тестов - приведены два скриншота бенчмарка скоростей работы.... ээээ.... физического и RAM дисков - "две сферические лошади в вакууме меряются копытами"! Тут даже ни циферки о скорости изменения работы SQL Server - сдаётся автор всё мерил на глаз - по своим ощущениям! Тем более нет писаний конфигураций до и после! Чтобы понять за счёт чего был прирост!
31. MrWonder 574 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 19 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 574 29.01.19 17:42 Сейчас в теме
(29) Павел, если Вам нужны тесты и статистика долговременной эксплуатации, Вы знаете что делать.
Почему Вы требуете их от меня? Я всего лишь скромный автор небольшой инструкции, не способный на удовлетворение Ваших желаний.
Ваши взгляды очень ценны. Спасибо Вам.
34. Darklight 19 29.01.19 17:47 Сейчас в теме
(33)Ничего от Вас не требую!
MrWonder; +1 Ответить
35. MrWonder 574 29.01.19 18:00 Сейчас в теме
(34) Спасибо. В качестве благодарности примите показатели io_stall_write_ms и io_stall_read_ms для TempDB в Ram и не в Ram.
37. Darklight 19 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 1077 22.04.19 14:18 Сейчас в теме
(20) Ну блин, столько текста и в конце противоречие самому себе.. тезис:
Ведь, насколько я знаю, все операции над temdb SQL сервер и так делает над таблицами (условно будем считать всё, что хранится в tembdb таблицами) с установленным внутренним приоритетом хранения в оперативной памяти (если её конечно достаточно)! То есть, временная таблица не будет выгружаться на диск, если для неё достаточно свободного места в оперативной памяти.


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

Коллега, а где же исследование, где доказательства, что на отдельном массиве будет быстрее? где описание экономического выигрыша?
71. Darklight 19 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 1077 22.04.19 15:32 Сейчас в теме
(71) явные противоречия, сначала топим против RAM, приводя доводы, что "все таблицы и так в памяти", а потом случай из практики - перенесите на другой диск и будет быстрее. Но если таблицы в памяти, то требования к диску и так минимальны и эффект должен быть очень слабым.
Это не моя статья. Я лишь написал своё предложение исходя из имеющегося у меня опыта.
собственно автор сделал тоже самое.
73. Darklight 19 22.04.19 15:57 Сейчас в теме
(72)"все таблицы и так в памяти" - где я такое говорил? Если бы все таблицы были в памяти то да, скорость чтения с диска была бы не важна (но вот скорость записи на диск, по-прежнему была бы важна). Но такая ситуация бывает не часто, даже для tempdb

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

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

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

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

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

в общем и в целом действительно можно провести большое исследование и проверить влияние кучи параметров и в ряде условий RAM будет полезен, в ряде вреден, всё индивидуально.
И если Вас статья подтолкнула на такую идею исследования, так welcome - сообщество спасибо скажет.
75. Darklight 19 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 19 29.01.19 18:01 Сейчас в теме
(32)Я ни в коей мере никого не отговариваю от использования RAM Диска для хранения tempdb - сам раньше грёзил этой идеей. Я лишь ратую за то, чтобы люди серьёзно относились к такому решению - грамотно взвешивали все за и против и понимали, что именно это действие реально ускорит хотя бы их личный частный случай.

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

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

Добавление же диска ssd (или любого другого диска к конфигурации) SQL сервера - не снижает его производительность. Вынос базы tempdb на отдельный (от рабочего) массив дисков, всегда даёт заметный выигрыш в производительности.
47. herfis 283 30.01.19 10:54 Сейчас в теме
(44) Вряд ли я ошибусь, если скажу что тут в основном люди, которым платят деньги не за фулл-тайм исследования. И мне, как и моему работодателю, вполне достаточно будет увидеть значительный прирост производительности на интегральных тестах "с" и "без", чтобы принять решение. Если по-вашему оно будет необдуманным, то и фиг с ним.
Другое дело, что бежать-переворачиваться ставить RAM-диск при отсутствии серьезных проблем с производительностью я бы тоже не стал. Просто не люблю без явной необходимости вводить новые сущности и увеличивать количество потенциальных точек отказа.
Но если, к примеру, есть проблема с производительностью и есть реальный запас по памяти, то вполне можно попробовать RAM-диск вместо того, чтобы решать вопрос с дополнительным приобретением дорогих серверных SSD.
48. Darklight 19 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 574 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 574 30.01.19 09:16 Сейчас в теме
(39) Перенесите профиль пользователя, под которым работает службы на другой, больший диск.
46. Darklight 19 30.01.19 10:46 Сейчас в теме
(42)Интересно, что же это даст? Хотя да, каталог temp файлов по умолчанию тоже переместится. Но только он.
45. Darklight 19 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 283 30.01.19 15:43 Сейчас в теме
(50) Суперская статья, полная суперских ссылок! Сенк.
52. MrWonder 574 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 574 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 574 01.02.19 11:05 Сейчас в теме
(59) Очень интересный опыт. Раскройте тему подробней, пожалуйста.
62. ogidni 01.02.19 11:54 Сейчас в теме
(60)Как видюха придет с ремонта. Напишу.
MrWonder; +1 Ответить
67. DonAlPatino 128 05.02.19 11:25 Сейчас в теме
(59) А можно подробнее? Это такая специфика Линукс, что можно видеопамять как часть файловой системы использовать? И, правильно ли я понимаю, что это сделано это не на серверной материнке/платформе?
61. herfis 283 01.02.19 11:32 Сейчас в теме
63. AntonSm 25 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 45 22.04.19 18:47 Сейчас в теме
(0)
P.S. Лишь внедрением RAM TempDB мы смогли ускорить закрытие месяца в ERP в два раза.


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

См. также

Набор скриптов для знакомства с SQL Server 195

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad) Администрирование СУБД

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

30.09.2019    8434    YPermitin    10       

Мониторинг высоконагруженной системы 36

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad) Администрирование данных 1С

Высоконагруженной системе (более 8000 клиентских сессий) мониторинг необходим. Про опыт использования инструментов для мониторинга – самописной системы информирования, написанной на C#, и конфигурации «Центр контроля качества» в связке с системой отображения данных Grafana, на конференции Infostart Event 2018 Education рассказал Олег Репников.

13.09.2019    3291    Repich    4       

Использование Zabbix для сбора информации о серверных вызовах и управляемых блокировках с сервера 1С Предприятия, работающего на платформе GNU/Linux 72

Статья Системный администратор Программист Нет файла v8 Linux Бесплатно (free) Администрирование данных 1С Zabbix

Описанные в данном опусе механизмы ни в коей мере не противопоставляются тому, что реализует КИП от 1С или какие-либо другие инструменты (решения)! Это всего лишь еще один взгляд на "проблему", который может быть полезен в некоторых ситуациях.

10.09.2019    6757    Sloth    11       

Руководство по SQL: Как лучше писать запросы (Часть 2) 33

Статья Системный администратор Программист Нет файла СУБД Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию продолжение перевода статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Первая часть доступна по ссылке https://infostart.ru/public/1115809/

03.09.2019    3256    w.r.    1       

Анализ производительности APDEX 65

Отчеты и формы Системный администратор Программист Внешний отчет (ert,erf) v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Отчет для просмотра и анализа замеров производительности в конфигурациях на базе БСП.

31.08.2019    2545    93    YPermitin    7       

Руководство по SQL: Как лучше писать запросы (Часть 1) 59

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Узнайте о антипаттернах, планах выполнения, time complexity, настройке запросов и оптимизации в SQL.

30.08.2019    4504    w.r.    0       

Использование Union вместо OR 5

Статья Системный администратор Программист Нет файла MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Derek Dieter "Using Union Instead of OR". Оригинал доступен по ссылке http://sqlserverplanet.com/optimization/using-union-instead-of-or.

22.08.2019    1408    w.r.    35       

Тюнинг производительности запросов в PostgreSQL 33

Статья Системный администратор Программист Нет файла PostgreSQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Brady Holt "Performance Tuning Queries in PostgreSQL ". Оригинал доступен по ссылке https://www.geekytidbits.com/performance-tuning-postgres/

31.07.2019    3058    w.r.    5       

Неочевидные проблемы производительности: важность системного подхода при анализе 50

Статья Программист Нет файла v8 Россия MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

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

19.07.2019    4058    Филин    12       

Ловля блокировок на связке "Microsoft SQL server - 1С" 37

Статья Системный администратор Программист Нет файла v8 v8::blocking MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Материал относится к базам данных на связке «1С - MS SQL Server». Один из способов отлова блокировок в бд 1С . Переход к управляемым блокировкам через режим "Автоматический и управляемый".

16.07.2019    3424    fhqhelp    0       

Настройка параметров PostgreSQL для оптимизации производительности 33

Статья Системный администратор Программист Нет файла PostgreSQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Ibrar Ahmed "Tuning PostgreSQL Database Parameters to Optimize Performance". Оригинал доступен по ссылке https://www.percona.com/blog/2018/08/31/tuning-postgresql-database-parameters-to-optimize-performance/

08.07.2019    3102    w.r.    13       

Сравнительное тестирование работы PostgreSQL с большими страницами Linux 6

Статья Системный администратор Программист Нет файла Linux Бесплатно (free) Производительность и оптимизация (HighLoad)

Представляю вашему вниманию перевод статьи Ibrar Ahmed "Benchmark PostgreSQL With Linux HugePages". Оригинал расположен по ссылке https://www.percona.com/blog/2018/12/20/benchmark-postgresql-with-linux-hugepages/

05.07.2019    1600    w.r.    6       

Настройка параметров ядра Linux для оптимизации PostgreSQL 33

Статья Системный администратор Программист Нет файла Linux Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Ibrar Ahmed "Tune Linux Kernel Parameters For PostgreSQL Optimization". Оригинал доступен по ссылке https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/

05.07.2019    2211    w.r.    1       

Анти-оптимизация: как мы ускорили запрос в 4 раза, сделав его неоптимальным 56

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Решение задач на 1С:Специалист Разработка

В этой статье приведен пример неочевидной "оптимизации" запроса, которая противоречит всем правилам, описанным в книгах для подготовки к сертификации "1С:Эксперт по технологическим вопросам", а также преподаваемым на курсах подготовки экспертов.

02.07.2019    5872    igordynets    119       

Сравнительное тестирование PostgreSQL на FreeBSD, CentOS, Ubuntu Debian и openSUSE 7

Статья Системный администратор Программист Нет файла PostgreSQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Данная статья является переводом оригинальной статьи Martin Kov&#225;&#269;ik "PostgreSQL benchmark on FreeBSD, CentOS, Ubuntu Debian and openSUSE" https://redbyte.eu/en/blog/postgresql-benchmark-freebsd-centos-ubuntu-debian-opensuse/ В ней рассматриваются тесты СУБД PostgreSQL 10.1 в приближенных к реальным условиям средах на различных unix-системах

30.06.2019    3335    w.r.    2       

Ускорение чтения правил обмена в УПП 1.3 в 20 раз! 65

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Способ оптимизации чтения правил обмена конвертации данных. Может понадобиться при большом размере правил и высокой периодичности обмена.

27.06.2019    4035    YPermitin    16       

Хотите снизить нагрузку на процессор сервера в 2 раза? 21

Статья Системный администратор Программист Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

В статье рассмотрено влияние частого запуска регламентных заданий на процессор сервера 1С.

27.06.2019    4012    Дмитрий74Чел    6       

Непридуманные истории по оптимизации. История 1 75

Статья Системный администратор Программист Нет файла v8 1cv8.cf Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

Первая статья из планируемого цикла об оптимизации приложений на базе 1С. Без теории. Одна практика.

13.06.2019    6758    Repich    117       

Оптимизация: неэффективные запросы 6

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Разработка

В большинстве случаев основной причиной медленной работы системы при многопользовательском режиме работы является блокировка данных СУБД (говорим про клиент-серверную версию). Блокировка - это не есть хорошо или плохо, это жизненно необходимая вещь при построении прикладной логики работы системы. Но блокировки таблиц, записей могут быть как вполне законными, так и далеко не всегда оправданными в каждой конкретной ситуации. Одной из самых распространенных причин неоптимальной блокировки ресурсов является некорректное написание запросов.

13.06.2019    2561    slayer-ekb    10       

За 5 шагов добавляем мониторинг счетчиков производительности серверов MS SQL и 1С 90

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Статистика базы данных Производительность и оптимизация (HighLoad)

Мы расскажем и покажем, как добавить данные счетчиков производительности серверов 1С и MS SQL в нашу базу мониторинга за 15 минут. Приведем список наиболее важных из них, опишем основные особенности.

28.05.2019    6927    ivanov660    5       

Не думать о секундах свысока... 55

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Несколько примеров оптимизации типовой конфигурации УТ11. Описанные приемы подходят для многих других конфигураций.

21.05.2019    4282    vasilev2015    21       

Альтернативная стратегия управления блокировками 45

Статья Программист Архив с данными v8 v8::blocking 1cv8.cf Россия MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

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

20.05.2019    3676    zhichkin    15       

Как работают управляемые блокировки 120

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

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

29.04.2019    12915    comol    198       

Странное потребление места на диске С 33

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Решение проблемы постоянного роста папки %AppData%/Local/Temp.

26.04.2019    10522    kuzyara    12       

Диспетчер Хранилища Запросов в SQL Server 2016+ (он же Query Store) 36

Статья Системный администратор Нет файла MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Если вы используете SQL Server 2016 или более позднюю версию, то у вас есть возможность использовать встроенную систему мониторинга, которая позволяет отслеживать самые базовые метрики выполняемых запросов и статистику ожиданий (потребления ресурсов). Эта информация позволяет быстро получить самые ресурсоемкие запросы с их планами и агрегированной статистикой выполнения.

26.04.2019    6942    Aleksey.Bochkov    7       

Включение встроенного в платформу механизма "Копии базы данных" и использование "Дата Акселератора". Новый стандартный механизм использования баз OLAP в 1С 49

Статья Системный администратор Программист Нет файла v8 Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

С версии 1С 8.3.14 в платформе появился новый функционал «Копии базы данных». В данной публикации я хочу рассказать, как включить использование данного механизма в платформе 1с и как его использовать для получения отчетов с копии базы данных, которая может быть вынесена на внешний сервер относительно текущей базы данных, а также как использовать систему «Дата акселератор», в которой база данных целиком размещена в оперативной памяти рабочего сервера кластера серверов «1С:Предприятия».

25.04.2019    8070    Elf1k    26       

Мониторим тяжелые запросы 28

Статья Системный администратор Программист Нет файла MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Мониторинг тяжелых запросов с сохранением результатов для истории.

22.04.2019    3864    ImHunter    8       

Копия базы 1С для отчетов. Или как выжить с тяжелой отчетностью 105

Статья Системный администратор Нет файла Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

Способы создания копии базы 1С для отчетов. Бэкапирование, репликация, AlwaysOn и другие страшные слова.

22.04.2019    7966    YPermitin    47       

5 простых шагов и 15 минут на разворачивание инструмента мониторинга проблем производительности базы 1С 201

Статья Системный администратор Программист Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

В этой статье мы разберем механизм использования конфигурации "Анализ технологического журнала" на практике, и всего через 15 минут работы вы получите функциональный, удобный инструмент мониторинга проблем производительности базы 1С.

18.04.2019    17631    ivanov660    40       

Самый быстрый шринк на Диком Западе 67

Статья Системный администратор Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad)

Шринк (shrink) базы данных. Наглядное объяснение что это, зачем, когда применять и как это можно ускорить.

17.04.2019    7009    YPermitin    44       

Как разбить базу на файлы и не сойти с ума 108

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Разбиение базы данных 1C на файлы и последующее сопровождение. Нюансы, грабли и прочее.

06.04.2019    8497    YPermitin    29       

Как одно изменение конфигурации PostgreSQL улучшило производительность медленных запросов в 50 раз 124

Статья Системный администратор Программист Нет файла v8 1cv8.cf Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

В связи с санкциями и другими событиями сейчас все более и более актуальна тема перевода ПО компаний на отечественное и свободное программное обеспечение. Одной из самых востребанных СУБД на рынке на данный момент является PostgreSQL - надежная, высокопроизводительная и хорошо масштабируемая СУБД, которая является прямым конкуретном таким крупным компаниям с их топовыми продуктами, как Oracle, IBM и Microsoft. Однако каждый, кто переходит на PostgreSQL, сталкивается с трудностями, прежде всего с настройкой и производительностью. Не обошли проблемы с производительностью "слоника" и меня. Предлагаю вашему вниманию перевод статьи "How a single PostgreSQL config change improved slow query performance by 50x" автора Pavan Patibandla, которая мне помогла улучшить производительность PostgreSQL.

18.03.2019    9664    w.r.    23       

Быстрее чем INSERT! BULK-операции и примеры использования 112

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Разработка Внешние источники данных Перенос данных из 1C8 в 1C8

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

09.03.2019    9574    YPermitin    38       

Простое программное решение проблем с блокировками SQL 17

Статья Системный администратор Программист Нет файла v8 v8::blocking 1cv8.cf Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

Описание одного из способов программного решения проблемы блокировок при проведении документов в клиент-серверной 1С.

06.03.2019    5760    dmitrydemenew    38       

Другой взгляд на APDEX и подсистему "Оценка производительности" 81

Статья Системный администратор Программист Нет файла 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Описание принципа работы подсистемы "Оценка производительности" из БСП, примеров использования, недостатках подсистемы, а также рассуждение о путях улучшения мониторинга производительности в системах 1С.

20.02.2019    8825    YPermitin    30       

Секционирование таблиц и индексов в мире 1С 157

Статья Системный администратор Программист Нет файла MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Говорим о секционировании таблиц и индексов для баз 1С. Способы применения, подводные камни и прочее.

10.02.2019    10870    YPermitin    53       

Производительность сервера 1С и фоновые задания 63

Статья Системный администратор Нет файла v8 1cv8.cf Россия Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

В падении производительности сервера 1С зачастую виноваты не регламентные / фоновые задания, они выполняют полезную работу. Но задания нельзя оставлять «наедине» с базой.

05.02.2019    10593    user715208    38       

Управляемые блокировки по полям из свойства "Поля блокировки данных" 5

Статья Программист Нет файла v8::blocking Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Разработка

Добрый день, коллеги! Хотелось бы поделиться обнаруженной особенностью работы механизма управляемых блокировок, а именно блокировке по полям, указанным в свойстве «Поля блокировки данных».

24.01.2019    3839    mshumakov    1       

Элементарный способ ускорить вашу 1С в два-три раза 71

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad)

Как ни странно, для меня оказалось открытием, что скорость работы 1С (всех процессорных задач) можно ускорить более чем в два раза элементарной настройкой Windows.

14.12.2018    27033    Aleksey81    43       

Создаем свои индексы для баз 1С. Со своей структурой и настройками! 123

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad)

Поговорим о неплатформенных индексах для информационных баз 1С. Об особенностях их использования, целесообразности и подводных камнях.

05.11.2018    11888    YPermitin    30       

Новый режим реструктуризации (обновление базы данных на сервере в режиме v2) 168

Статья Системный администратор Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Данная статья скорее является заметкой и отчетом об успешном использовании нового механизма реструктуризации баз данных 1С. Актуально для больших баз данных.

31.10.2018    18130    Dach    46       

Нетривиальные подходы в решении всем известных проблем: ускорение «больших» документов в 1С и ускорение поиска по подстроке. Как добиться эффекта в разы? 62

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Часто у пользователей 1С поиск информации по большим спискам данных по подстроке занимает продолжительное время. Павел Баркетов рассматривает причины торможения запросов с поиском по подстроке и описывает возможности и подходы к их оптимизации и ускорению. Также в статье разобраны причины длительного проведения «больших» документов (более 10 000 строк) и даны рекомендации по ускорению этих операций.

30.08.2018    10677    gallam99    31