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

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

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

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

При работе 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 в два раза.

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

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

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


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


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

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

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

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

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

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

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

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

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

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

Добавление же диска ssd (или любого другого диска к конфигурации) SQL сервера - не снижает его производительность. Вынос базы tempdb на отдельный (от рабочего) массив дисков, всегда даёт заметный выигрыш в производительности.
47. herfis 365 30.01.19 10:54 Сейчас в теме
(44) Вряд ли я ошибусь, если скажу что тут в основном люди, которым платят деньги не за фулл-тайм исследования. И мне, как и моему работодателю, вполне достаточно будет увидеть значительный прирост производительности на интегральных тестах "с" и "без", чтобы принять решение. Если по-вашему оно будет необдуманным, то и фиг с ним.
Другое дело, что бежать-переворачиваться ставить RAM-диск при отсутствии серьезных проблем с производительностью я бы тоже не стал. Просто не люблю без явной необходимости вводить новые сущности и увеличивать количество потенциальных точек отказа.
Но если, к примеру, есть проблема с производительностью и есть реальный запас по памяти, то вполне можно попробовать RAM-диск вместо того, чтобы решать вопрос с дополнительным приобретением дорогих серверных SSD.
48. Darklight 22 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 609 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 609 30.01.19 09:16 Сейчас в теме
(39) Перенесите профиль пользователя, под которым работает службы на другой, больший диск.
46. Darklight 22 30.01.19 10:46 Сейчас в теме
(42)Интересно, что же это даст? Хотя да, каталог temp файлов по умолчанию тоже переместится. Но только он.
45. Darklight 22 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 18 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 365 30.01.19 15:43 Сейчас в теме
(50) Суперская статья, полная суперских ссылок! Сенк.
52. MrWonder 609 30.01.19 15:45 Сейчас в теме
(50) Спасибо. Но мой домашний m2.960pro пока не вырос до 970 (((
55. viptextil1 17 01.02.19 08:43 Сейчас в теме
На мой взгляд - спорное предложение. Дело в том, что сейчас все часто используемые области данных и так кэшируются в памяти. Создавая рамдиск - фрагментируете ресурсы (память) и уменьшаете объем кэша, что может отрицательно сказываться на производительности.
56. user751351 01.02.19 09:13 Сейчас в теме
и никто почему-то не говорит, что работа tempdb с несколькими файлами распределяется равномерно на все файлы, причем в % отношении размера конкретного файла tempdb к общему размеру базы. т.е. если файлы 10G в RAM и 90G на обычном диске, то и использоваться будет 10% и 90% соответственно от запрашиваемого объема на ОДНОЙ задаче!!! не делайте так! и это никак не связано с параллелилизмом, который в большинстве случаев приводит к замедлению на системах с высокой нагрузкой.
57. Indgo 01.02.19 10:15 Сейчас в теме
Автору спасибо и лайк, не смотря на радикальное решение.
Хотелось бы узнать что будет если выдернуть сервер из розетки?
Не уйдет ли MS SQL в защищенный режим?

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

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


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

См. также

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

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

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

26.04.2019    10701    0    Aleksey.Bochkov    7    

Автоматическая классификация ошибок технологического журнала

Технологический журнал v8 1cv8.cf Бесплатно (free)

В статье обсудим пример практической настройки конфигурации «Мониторинг производительности» для автоматической классификации ошибок по группам/кластерам на данных текстов описания ошибок. Используем механизм векторной модели текстов и косинусное сходство между ними.

25.06.2020    1761    0    ivanov660    12    

Выбор процессора для 1С: конец споров или начало?

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

Периодически занимаясь исследованиями производительности я повидал много решений. Делюсь некоторыми выводами на основании теста Гилева и собственных мыслей.

25.05.2020    7403    0    starik-2005    216    

Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

Производительность и оптимизация (HighLoad) Администрирование СУБД Технологический журнал Структура метаданных v8::Запросы Бесплатно (free)

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

24.05.2020    5891    0    DataReducer    22    

Опыт миграции из собственного датацентра в облако AWS Промо

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

Хотя данная публикация и не имеет прямого отношения к 1С, она может быть интересна тем, кто занимается крупными базами данных на MS SQL Server. Описывается опыт миграции баз данных в облако AWS в компании glassdoor.com, где я занимался этим проектом. Это первый драфт текста, получившийся довольно скомканным - в процессе буду дополнять.

29.07.2018    11147    0    Aleksey.Bochkov    9    

Учимся готовить кроликов с редиской: опыт применения Rabbit MQ и Redis в интеграционных проектах

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

При построении мощных производительных отказоустойчивых решений для интеграции во всем мире активно используются технологии обработки очередей сообщений с помощью брокера RabbitMQ и кэш-сервера Redis. О практическом опыте использования этих технологий при построении ИТ-ландшафта, включающего системы на 1С, на конференции Infostart Event 2019 Inception рассказал Сергей Наумов.

12.05.2020    4389    0    SergeyN    3    

Ок, Лариса! Мониторинг проблем производительности с применением нейронных сетей

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

Проводить мониторинг производительности вручную, выявляя закономерности в куче графиков и десятках таблиц, довольно сложно. Но это не значит, что разбираться с инцидентами нужно только после жалоб от пользователей. О том, как обучить нейронную сеть и заставить ее оповещать о проблемах, на конференции Infostart Event 2019 Inception рассказал начальник сектора разработки ООО «Группа Полипластик» Владимир Крючков.

27.04.2020    3573    0    ivanov660    5    

Пример поиска ошибок в технологическом журнале

Технологический журнал Производительность и оптимизация (HighLoad) Бесплатно (free)

Примеры bash - скриптов для поиска ошибок в технологическом журнале.

23.04.2020    2359    0    vasilev2015    6    

Исследование технологического журнала 1С при помощи регулярных выражений в блокноте Промо

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

Все из тех, кто пробовали сдать на сертификат "Эксперт по технологическим вопросам 1С", сталкивались с методикой ЦКТП - разбор файлов технологического журнала при помощи консоли bash. Я, в свою очередь,внёс изменения в данную методику. Мне хотелось достичь более понятного вида и сфокусироваться на Perl, в качестве предпочтительного средства обработки файлов ТЖ. Вот что из этого вышло:

30.10.2017    28740    0    MrWonder    42    

Фреймворк "Мониторинг производительности". Руководство пользователя

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

Описание и руководство "Мониторинг производительности": краткое описание конфигурации, сборник из статей, примеров - собрано в одном файле.

21.04.2020    2758    0    ivanov660    3    

Эти занимательные временные таблицы

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

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

06.04.2020    9946    0    YPermitin    0    

Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

Производительность и оптимизация (HighLoad) WEB Интеграция Мобильная разработка Администрирование веб-серверов v8 Бесплатно (free)

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

31.03.2020    11061    0    informa1555    21    

Опыт оптимизации и контроля производительности в БД с 3000 пользователей Промо

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

Данная статья написана по материалам доклада, прочитанного на Конференции Инфостарта IE 2014 29-31 октября 2014 года. Меня зовут Сергей, являюсь руководителем отдела оптимизации и производительности систем в компании "Деловые линии". Цель этого доклада – поделиться информацией о нашем опыте работы с большой базой на платформе 1С, с чем пришлось столкнуться, как удалось обеспечить работоспособность. Уверен, что вам будет интересно, так как подобной информацией мало кто делится, да и про само существование таких систем их владельцы стараются не рассказывать, максимум про это «краем глаза» упоминают участвовавшие в проекте вендоры. **update от 04.03.2016 по вопросам из комментариев

05.08.2015    60326    0    Sergey.Noskov    119    

Многострочный контекст событий

Производительность и оптимизация (HighLoad) Технологический журнал v8 Бесплатно (free)

Разбор технологического журнала с группировкой событий по первой или последней строке многострочного контекста.

31.03.2020    2733    0    vasilev2015    9    

Анализ взаимоблокировок

Производительность и оптимизация (HighLoad) Технологический журнал v8 Бесплатно (free)

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

20.03.2020    4014    0    vasilev2015    21    

Многопоточность

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

Увеличиваем скорость загрузки данных в 20 раз. Как следует использовать многопоточность и готовый модуль для внедрения.

18.03.2020    6047    0    kaliuzhnyi    43    

Долго открывается конфигуратор Промо

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

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями), чтобы повысить производительность 1С:Предприятие 8 в ряде случаев.

22.04.2015    40020    0    Gilev.Vyacheslav    1    

Улучшение пооперационного планирования в 1С:ERP 2.4 внешними средствами

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

Задача построения оптимального производственного расписания требует сравнения тысяч и десятков тысяч вариантов. Выполнять такие вычисления средствами платформы 1С Предприятие нецелесообразно. Как реализовать пооперационное планирование с использованием генетических алгоритмов и параллельных вычислений в докладе на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «ИНТЕХ» Сергей Сафаров.

02.03.2020    4365    0    ildarovich    7    

Повышенная нагрузка на диски сервера баз данных SQL Server Промо

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

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

15.03.2015    39305    0    gallam99    17    

Делаем быстрее POSTGRESQL COUNT (*)

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

Предлагаю вашему вниманию перевод статьи Laurenz Albe "POSTGRESQL COUNT(*) MADE FAST". Оригинал доступен по ссылке https://www.cybertec-postgresql.com/en/postgresql-count-made-fast/

28.02.2020    2190    0    w.r.    1    

Простое обнаружение проблем производительности в PostgreSQL

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

Предлагаю вашему вниманию перевод статьи Hans-Jürgen Schönig "DETECTING PERFORMANCE PROBLEMS EASILY IN POSTGRESQL". Оригинал доступен по ссылке https://www.cybertec-postgresql.com/en/detecting-performance-problems-easily-in-postgresql/ Актуально для всех 1С ников, перешедших с MS SQL на Postgres

20.02.2020    3520    0    w.r.    4    

Планы запросов - это просто! Разбор оптимизаций запросов PostgreSQL на живых примерах

Производительность и оптимизация (HighLoad) v8::Запросы Бесплатно (free)

Проблема быстродействия 1С напрямую зависит от производительности запросов. Но как понять механику работы СУБД с помощью плана запроса? Андрей Овсянкин и Никита Грызлов на конференции Infostart Event 2019 Inception подробно рассмотрели алгоритм работы с планом запроса СУБД PostgreSQL, полученным из технологического журнала, и рассказали, на что обратить внимание, чтобы оптимизировать работу системы.

17.02.2020    7985    0    Evil Beaver    13    

Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С Промо

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

Описано как из 1С, с помощью безобидной на первый взгляд обработки, можно сделать неработоспособным SQL сервер. Предложены меры, позволяющие избежать этого.

22.01.2014    66415    0    yuraos    112    

Держи данные в тепле, транзакции в холоде, а VACUUM в голоде

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

Чтобы база работала быстро – в ней нужен порядок. Это касается как MS SQL, так и PostgreSQL. Как настроить базу, чтобы в ней поддерживался порядок, какие регламентные операции нужно проводить, чтобы данные чистились, индексы перестраивались и оперативная память высвобождалась в своём выступлении на конференции Infostart Event 2019 Inception поделился руководитель ИТ в компании «ИнфоСофт» Антон Дорошкевич. 

07.02.2020    8709    0    a.doroshkevich    17    

Оптимизатор запросов. Вторая часть

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

Продолжение статьи об оптимизаторе запросов. Во второй части мы попробуем создать свой оптимизатор и попутно разберемся с такими вопросами, как: хранение файлов; индексы; статистика.

23.01.2020    5822    0    darkdan77    59    

Улучшаем производительность 1С. Рекомендации

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

Каждый уважаемый разработчик 1С сталкивался или столкнется с вопросом производительности высоконагруженных систем. В статье агрегирован основной набор рекомендаций, который позволит повысить производительность системы. Эти рекомендации должны быть просто must have по определению.

23.01.2020    7112    0    Kaval88    26    

Ускоряем списание партий УПП 1.2 / 1.3 / УТ 10.3 Промо

Производительность и оптимизация (HighLoad) v8 УТ10 УПП1 Бесплатно (free)

Не секрет, что многие пользователи, использующие партионный учет (а таких очень много, даже среди огромных холдингов, несмотря на пропаганду РАУЗ) при больших нагрузках сталкиваются с резким замедлением списания партий.

21.06.2013    53205    0    Антон Ширяев    116    

Атака сервера кнопонажималкой

Нагрузочное тестирование Инструментарий разработчика Бесплатно (free)

Чтобы убедиться, что продукт выдержит планируемую нагрузку, необходимо провести нагрузочное тестирование – написать сценарии пользовательских действий и запустить их в несколько потоков, чтобы заранее найти проблемы в бизнес-логике и «узкие места». О том, как упростить написание сценариев тестирования для конфигурации Тест-центр с помощью фреймворка Vanessa Automation на конференции Infostart Event 2019 Inception рассказал ведущий программист компании «ПервыйБИТ» Никита Грызлов.

20.01.2020    5344    0    nixel    22    

Мониторим производительность с помощью 1С RAS

Инструментарий разработчика Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Подключаемся и анализируем данные через 1С RAS. Необходимо выполнить 5 пунктов и серьезный инструмент мониторинга будет у вас в руках.

19.12.2019    9864    0    ivanov660    16    

История роста и работы команд 1С в условиях HighLoad и BigData

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

Современные потребности бизнеса заставляют программистов 1С решать все более сложные задачи. А главные требования, которым необходимо соответствовать, – вовремя поставлять ценности высокого качества. С какими сложностями приходится сталкиваться в работе программистам в динамично развивающейся брокерской сфере, и как их решают, на конференции Infostart Event 2018 Education рассказал начальник отдела интеграции БКС Технологии Сергей Артемов.

11.11.2019    6950    0    user826155    11    

Сравнение скорости работы 1C+MSSQL и файлового варианта Промо

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

На форумах постоянно задается один и тот же вопрос: почему 1C+MSSQL медленнее обрабатывает запросы чем файловая? Затем обычно идет «флуд» на несколько десятков страниц. Есть два популярных «течения» в таких форумах — одни говорят что для клиент-серверного варианта это нормально, файловый вариант всегда должен работать быстрее, другие говорят что 1С плохо работает с субд. В результате «баталий и выяснения отношений» на форумах люди расходятся при своих мнения.

19.02.2013    53852    0    Gilev.Vyacheslav    46    

Весёлые картинки о работе Performance Monitor на Windows Server 2016 Std по мотивам расследования потери производительности на базе 1С

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

Данная публикация посвящена одной особенности Performance Monitor на Windows Server 2016 Std. Как понимать графики Performance Monitor на Windows Server 2016 Std при расследовании проблем в работе 1С.

22.10.2019    6915    0    EugeneSemyonov    11    

Обслуживание баз данных. Не так просто, как кажется

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

Считаете, что обслуживание индексов и статистик дело простое? Что ж, это не всегда так.

14.10.2019    16307    0    YPermitin    28    

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

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

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

30.09.2019    20608    0    YPermitin    14    

Параллельные вычисления в 1С 8 Промо

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

Решение позволяет ускорять выполнение запросов в 1С 8 в отчетах путем их параллельного выполнения в разных потоках.

11.02.2013    29610    0    gallam99    19    

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

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

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

13.09.2019    8456    0    Repich    5    

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

Администрирование данных 1С Zabbix v8 Бесплатно (free)

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

10.09.2019    17413    0    Sloth    24    

Подбор оборудования для информационных систем на платформе 1С

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

При подборе оборудования по рекомендациям с сайта ИТС возникает противоречие: проводить ли нагрузочные тесты, чтобы определить возможную нагрузку, или достаточно просто взять данные из таблиц статистики? О том, какую тактику применить в том или ином случае, на конференции INFOSTART EVENT 2018 Education рассказал начальник отдела разработки компании IBS Филиппов Евгений.

09.09.2019    8565    0    jf2000    8    

Ubuntu vs CentOS vs Win2k8 vs Debian: производительность PostgreSQL Промо

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

Хотя интернет уже переполнен статьями о "правильной" настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самую большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно. Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?

03.11.2012    41800    0    madmpro    32    

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

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

Предлагаю вашему вниманию продолжение перевода статьи 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    7101    0    w.r.    2    

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

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

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

31.08.2019    9767    2    YPermitin    7    

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

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

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

30.08.2019    10147    0    w.r.    19    

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

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

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

22.08.2019    3751    0    w.r.    35    

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

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

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

31.07.2019    7107    0    w.r.    5    

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

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

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

19.07.2019    8435    0    Филин    12    

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

Производительность и оптимизация (HighLoad) v8 v8::blocking Бесплатно (free)

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

16.07.2019    9076    0    fhqhelp    0    

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

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

Предлагаю вашему вниманию перевод статьи 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    6578    0    w.r.    19    

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

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

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

05.07.2019    4419    0    w.r.    6    

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

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

Предлагаю вашему вниманию перевод статьи 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    5210    0    w.r.    2