Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
MS SQL разное время insert 'a
|
|||
|---|---|---|---|
|
#18+
Добрый день! Прошу помощи. Имеется MS SQL 2016 (13.0.4001.0). 256Гб ОЗУ, 32 ядра Xeon. Большая БД - около 50Тб (содержит изображения). Модель восстановления БД - Simple. Существуют две большие таблицы (более 600кк строк в каждой): Info и Image. Scheme Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. Записываем данные через приложение .NET Core, используя System.Data.SqlClient и хранимую процедуру (есть в схеме). Упрощенно алгоритм выглядит так: каждую запись по одной записываем в Info (там только текст), получаем ID и записываем изображение с этим ID в Image. SQL установлен с настройками по умолчанию. База лежит на 5 разных RAID массивах, емкостью по 10Тб. Нагрузка на ЦП низкая, очереди на дисках нет. Входные данные всегда усреднено одинаковые. Подсчитываю время записи на 1000 записей. Проблема: время записи на 1000 "строк" постоянно прыгает. К примеру, 1-2 часа пишет со скоростью 20 сек на 1000 "строк", после начинает тратить на это 8 секунд. Работает так от нескольких минут до нескольких часов, снова сваливается в 20 сек. Проверял все это ночью, нагрузки клиентов в данный период нет - подтверждается логами приложения и особенностью работы. Индексы перестраивал полностью на Info, на Image фрагментации нет. Не помогает. Такое ощущение, что SQL выполняет какие-то регламентные операции, чистит кеш или что-то там пересчитывает, работает какое-то время, потом снова тупит. Как понять, с чем может быть связано это рендомная запись при одинаковых условиях? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2018, 13:08 |
|
||
|
MS SQL разное время insert 'a
|
|||
|---|---|---|---|
|
#18+
DiZarКак понять, с чем может быть связано это рендомная запись при одинаковых условиях? Как вы убедились, что условия разные? Вы размер записываемых данных посчитали? Вы помониторили нагрузку на сервере, когда "снова сваливается в 20 сек"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2018, 13:19 |
|
||
|
MS SQL разное время insert 'a
|
|||
|---|---|---|---|
|
#18+
Гавриленко Сергей АлексеевичDiZarКак понять, с чем может быть связано это рендомная запись при одинаковых условиях? Как вы убедились, что условия разные? Вы размер записываемых данных посчитали? Вы помониторили нагрузку на сервере, когда "снова сваливается в 20 сек"? В моменты быстрой записи и медленной смотрел текущие операции скриптом: Скрипт по текущим операциям select session_id, status, wait_type, command, last_wait_type, percent_complete , qt.text sql1 , total_elapsed_time/1000 as [total_elapsed_time, sec], wait_time/1000 as [wait_time, sec], (total_elapsed_time - wait_time)/1000 as [work_time, sec] from sys.dm_exec_requests as qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt Сравнивал загрузку ЦП, количество очередей на дисках, ожидающие запросы в мониторинге ресурсов в Managment Studio. В двух случаях все эти показатели были одинаковыми, кроме записи на диск. В момент "быстрой" работы SQL пишет 7-8 метров в секунду в лог и столько же в файлы БД. При медленной работе скорость записи составляет 3 Мб\сек. Объем данных не замерял, сделаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2018, 13:51 |
|
||
|
MS SQL разное время insert 'a
|
|||
|---|---|---|---|
|
#18+
Текущих операций в эти моменты, кроме самого insert вообще нет. Т.е. SQL никто никто не мешает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2018, 13:54 |
|
||
|
MS SQL разное время insert 'a
|
|||
|---|---|---|---|
|
#18+
DiZar, значит в этот момент что-то еще хочет получить доступ к диску. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2018, 13:56 |
|
||
|
MS SQL разное время insert 'a
|
|||
|---|---|---|---|
|
#18+
DiZar, размер/ приращение лога какой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2018, 13:57 |
|
||
|
MS SQL разное время insert 'a
|
|||
|---|---|---|---|
|
#18+
Посмотрите нагрузку на файлы через sys.dm_io_virtual_file_stats. Нехорошо, если кол-во байт записанных / прочитанных отличается между файлами данных, или отличается ожидание на одну операцию ввода-вывода между файлами. Так же сраните показатели между периодами быстрой и медленной работы. З.Ы. Ну и самое главное: хотите писать быстро -- прикрутите bulk-вставку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2018, 14:02 |
|
||
|
MS SQL разное время insert 'a
|
|||
|---|---|---|---|
|
#18+
TaPaKDiZar, размер/ приращение лога какой?И файлов данных. Настроено ли instant file initialization? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2018, 14:04 |
|
||
|
MS SQL разное время insert 'a
|
|||
|---|---|---|---|
|
#18+
Как-то сомнительно, что размер приращения такой, что он два часа диск пилит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2018, 14:09 |
|
||
|
MS SQL разное время insert 'a
|
|||
|---|---|---|---|
|
#18+
Владислав КолосовКак-то сомнительно, что размер приращения такой, что он два часа диск пилит.Степень точности измерения продолжительности медленной работы не известена. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2018, 14:12 |
|
||
|
MS SQL разное время insert 'a
|
|||
|---|---|---|---|
|
#18+
TaPaKDiZar, размер/ приращение лога какой? 1024 Мб sys.dm_io_virtual_file_stats попробую посмотреть чуть позже. bulk-вставку пробовали, что-то остановило нас, постараюсь вспомнить. И файлов данных. Настроено ли instant file initialization? Файлам данных сейчас разрешено расти только одному по 2048 Мб. Instant file initialization не настраивал, только сегодня прочитал про это. Но, я нарезал свободного места вперед. Сейчас свободного места порядка 600Гб. Это сутки работы без авторасширения. Замерил по последним логам периоды, оказывается закономерность есть: 32 минут медленной 15 минут быстрой 36 минут медленной 16 минут быстрой Еще момент забыл указать. В субботу я перестроил все индексы и поставил запись, в надежде, что все залетает. Чуда не произошло - все тупило. Потом взял и нарезал вперед 300 Гб места и запись пошла очееень быстро. Я думал, что решил проблему, но вчера она возникла снова даже при свободном месте. И добавление места во все файлы также не помогает. Логи SQL кстати чистые. Смущает именно цикличность .... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2018, 14:31 |
|
||
|
MS SQL разное время insert 'a
|
|||
|---|---|---|---|
|
#18+
DiZar, посмотрите на события file growths и chekpoint. Вполне может быть что дело в них... Ну и чем больше индексов тем медленней вставка ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2018, 14:54 |
|
||
|
MS SQL разное время insert 'a
|
|||
|---|---|---|---|
|
#18+
DiZar, Сохраните для пишущей сессии содержимое sys.dm_exec_session_wait_stats в начале и конце медленных периодов. Потом посмотрите на чем были ожидания. А может у вас сервер в виртуальной среде и чудит именно она? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2018, 15:14 |
|
||
|
MS SQL разное время insert 'a
|
|||
|---|---|---|---|
|
#18+
Все рекомендации проверю вечером, отпишусь, спасибо всем! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2018, 16:58 |
|
||
|
MS SQL разное время insert 'a
|
|||
|---|---|---|---|
|
#18+
Для проформы вопрос: лог лежит, конечно же на отдельном диске? не вместе с каким-либо сегментом данных? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2018, 17:00 |
|
||
|
MS SQL разное время insert 'a
|
|||
|---|---|---|---|
|
#18+
На виртуальных дисках и процессорах вообще все что угодно может быть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2018, 18:41 |
|
||
|
MS SQL разное время insert 'a
|
|||
|---|---|---|---|
|
#18+
Новости следующие. 1. Да, это виртуалка. Доступа к администрированию у меня нет. Что происходит на гипервизоре для меня загадка. 2. Думаю дело не в instant file initialization, т.к. место я нарезал в файлах руками на пару дней вперед. Тоже самое с file growths, маловероятно. 3. Сhekpoint, прочитал. Идя хорошая, но, насколько я понял, это влияло бы на на каждую запись. Хотя, судя по настройкам, у меня автоматические контрольные точки (в SSMS в настройках стоит 0, что якобы говорит от автоматических, но команда "SELECT name, target_recovery_time_in_seconds FROM sys.databases WHERE name = 'My_DB" выдает значение "60". Что свидетельствует о косвенных контрольных точках. Переложить лог на отдельный диск, собрать статистику sys.dm_exec_session_wait_stats и остальные рекомендации проверить не успел, потому происходит что-то странное. Я решил считать количество записанных Мб, добавил это в логи. Перезалил ПО и запустил.....уже 2 часа запись идет на идеальной скорости. Хотя до этого я перезаливал его раз 20 для сбора статистики и ничего такого не было. Начинаю склоняться к версии "На виртуальных дисках и процессорах вообще все что угодно может быть." Продолжаю наблюдение..... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2018, 22:50 |
|
||
|
MS SQL разное время insert 'a
|
|||
|---|---|---|---|
|
#18+
DiZar, "лучшие практики" рекомендуют использование физических дисков на виртуальных машинах (одно из главных требований производительности), но если вы не можете повлиять на настройки, то придется смириться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2018, 10:58 |
|
||
|
MS SQL разное время insert 'a
|
|||
|---|---|---|---|
|
#18+
DiZar, вот хорошая статья на Хабре https://habr.com/post/414269/ Там, в общем то, прописные истины в отношении логфайлов, но прочесть полезно. Да, в случае высоконагруженных систем, в частности - в случае если вы заливаете данные терабайтами - логи желательно держать на отдельных физических дисках, либо на виртуальных, но физически расположенных на отдельной, предназначенной только для этой БД и только для логов - группе дисков, причем размер виртуального диска должен быть фиксированным. Кстати, размер в виртуального диска с данными - тоже крайне желательно делать фиксированным. И в любом случае крайне нежелательно помещать логи и данные на один диск, даже виртуальный. Кстати, нужно проверить, сколько иопсов у вас выделено под диск, на котором расположены логи. Пропускная способность, например, может быть зарезана сверху. Если у вас, к примеру, 300 иопсов на диске с логами - вы на больше 300 операций в секунду и не сделаете, причем не важно, по сколько вы будете заливать на диск - пакетом по 1000 записей или по 1 записи - всё равно максимум 300 таких пакетов в секунду. Но по 1000 записей это будет, грубо говоря, 300 тыс. записей максимум, а по одной - 300 :-) Ну, речь о верхней планке, разумеется. Поправьте, если ошибаюсь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2018, 16:14 |
|
||
|
MS SQL разное время insert 'a
|
|||
|---|---|---|---|
|
#18+
uaggster, спасибо за статью! Полезные вещи всегда читаю и сохраняю. IOPS могу замерить, но для этого придется остановить систему, чтобы замерять в "чистых" условиях. Пока этого делать не хочется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2018, 21:35 |
|
||
|
MS SQL разное время insert 'a
|
|||
|---|---|---|---|
|
#18+
Всем спасибо. Похоже, отгадка нашлась. СХД занимается беками по расписанию. В этом причина такого поведения СУБД. Тема закрыта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2018, 22:10 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39725204&tid=1688859]: |
0ms |
get settings: |
6ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
47ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
61ms |
get tp. blocked users: |
2ms |
| others: | 240ms |
| total: | 389ms |

| 0 / 0 |
