|
|
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
hi all Есть ФБ, собран из сегодняшних сырцов. Есть пустая база с FW = OFF, page_size=4096. И есть вот такой скрипт, который сечас выполняется: (создаёт SP, таблицы + индексы, затем стартует select * from SP for update) Код: 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. Пример вывода этого скрипта: Код: plaintext 1. 2. 3. 4. Параллельно с этим, в отдельном окне пляшет iostat с логированием своего вывода в файлик. Данные в iostat'e обновляются каждую секунду. Скачок в 10 сек, как видим, был в 19:05:50. Значит, можно глянуть в лог iostat'a за период с 19:05:20 по 19:06:20 и попытаться понять, чем был вызван этот тупняк. Фрагмент этого лога - в аттаче. Поможыте понять, кто в линухе силён: на что обратить внимание ? В упор не вижу, чем период 19:05:40...19:05:50 отличается от остальных: %iowait везде примерно одинаковый, на уровне 6...8%. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2014, 19:26:35 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
"Продолжаем разговор" (С) :) Через 12 ч после начала теста вывод execute block'a состоит сплошняком из "перлов": Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. То есть, 10'000 строк в TDETL + 1 строка в TMAIN добавляются то 8, а то и 80 сек. Пик был (пока что) в 07:31:51 и составил 6 минут 46 сек %-) Чем его объяснить - то тайна велика есмь Ибо логи iostat и vmstat за этот временн о й отрезок (почти 7 минут) - ничего выдающегося не содержат, если сравнивать их показатели с другим временем. Кому интересно - посмотрите в аттач, там два фрагмента этих логов, с 07:24:43 по 07:32:00. Насколько могу понять, IO "пишет себе и пишет", не больше и не меньше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 10:19:05 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
FW-OFF? P.S. Топик не читал. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 10:45:20 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
авторЕсть ФБ, собран из сегодняшних сырцов. Есть пустая база с FW = OFF , page_size=4096. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 10:55:58 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, что мешает выставить MaxUnflushed* и посмотреть, не исчезнут ли "затыки"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 10:58:47 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Вообще-то говоря, состояние базы в момент, когда тест закончится, у мну есть, т.к. сейчас идёт второй "забег". Вот оно: gstat -r Код: plaintext 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. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. Когда база пустая, то статистика добавления 100 строк в TMAIN и 10000 строк в TDETL следующая: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Когда же таблица TMAIN содержит 2 млн, а TDETL - 200 млн строк, то коленкор таков: Код: plaintext 1. 2. 3. 4. 5. 6. 7. (время вполнения намеренно выкинул, т.к. оно всё время "скачет" - см пост выше, 15400933 ). Я понимаю, что там random IO из-за поиска места в индексах для вставки ключей - но всё-таки число фетчей только в полтора раза выше прежнего (363208 / 232208). На что время-то уходит такое (по нескольку минут!) при работе только ОДНОГО аттача ? ЗЫ. На хосте ничего больше, кроме ФБ, не молотит. Только рядом скрипты с линуховым мониторингом: iostat, vmstat (сейчас вот еще iotop lобавил). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 11:10:45 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
dimitrчто мешает выставить MaxUnflushed* и посмотреть, не исчезнут ли "затыки"?пардон, не увидел этот пост вовремя. Сейчас уже буду ждать окончания молотьбы, там дошло аж до 180 млн: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Правильно ли я понимать, что оба maxUnflushed* надо просто выставить в какие-то большие числа ? (например, maxUnflushedWrites = 2048M) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 11:14:33 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
ТаблоидЯ понимаю, что там random IO из-за поиска места в индексах для вставки ключей - но всё-таки число фетчей только в полтора раза выше прежнего (363208 / 232208). а глубина индексов в 4 и даже 5 уровней тебя не смущает? Сотни миллионов записей на базе со страницей 4КБ - это садомазохизм такой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 11:19:09 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
ТаблоидПравильно ли я понимать, что оба maxUnflushed* надо просто выставить в какие-то большие числа ? (например, maxUnflushedWrites = 2048M) боже ты мой, конечно неправильно. Спровоцируй регулярный частый сброс файлового кеша, чтобы оно не накапливалось. Правда, если ты все 200млн вливаешь в одной транзакции, то эта настройка тебе не поможет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 11:23:05 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоидЯ понимаю, что там random IO из-за поиска места в индексах для вставки ключей - но всё-таки число фетчей только в полтора раза выше прежнего (363208 / 232208).а глубина индексов в 4 и даже 5 уровней тебя не смущает? Сотни миллионов записей на базе со страницей 4КБ - это садомазохизм такой?1. Индексы такой глубины - это приговор на "вечные тормоза" ? Если да, то чем это объяснить, почему на глубине 3 всё пучком, а 5 -уже "куку" ? Затратами на расщепление листовых страниц и всех вышележащих уровней или еще чем-то ? 2. Страница 4К - это только первая фаза нашей эстафеты Дальше надо будет на 8 и 16 К проверить. Таково "задание Партии". Кста! А ведь тут не раз проскакивала мантра: "большая страница - хорошо для выборок, но плохо для ДМЛ"... Ну так у мну страница, как раз "хорошая" по размеру для DML, нет разве ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 11:34:13 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоидПравильно ли я понимать, что оба maxUnflushed* надо просто выставить в какие-то большие числа ? (например, maxUnflushedWrites = 2048M)боже ты мой, конечно неправильно. Спровоцируй регулярный частый сброс файлового кеша, чтобы оно не накапливалось. Правда, если ты все 200млн вливаешь в одной транзакции, то эта настройка тебе не поможет...Дык не вопрос, могу сделать всё в цикле, чтобы там автономная транзакция запихивала по 10 тыс в tmain + 1 млн в tdetl. Только ты скажи всё-таки: какие значения поставить для maxUnflushed* ? А то опять пальцем в небо ткну и время потеряю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 11:36:47 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Таблоидтут не раз проскакивала мантра: "большая страница - хорошо для выборок, но плохо для ДМЛ"... Ну так у мну страница, как раз "хорошая" по размеру для DML, нет разве ? это правда для вменяемых размеров базы, когда глубина индексов не зашкаливает. Иначе ахтунг в индексах очень быстро перевешивает все остальные критерии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 12:14:31 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Таблоидне вопрос, могу сделать всё в цикле, чтобы там автономная транзакция запихивала по 10 тыс в tmain + 1 млн в tdetl. Только ты скажи всё-таки: какие значения поставить для maxUnflushed* ? А то опять пальцем в небо ткну и время потеряю. попробуй настроить на коммит не реже чем раз в 1 млн записей, лучше меньше. Т.е. я бы предложил порции в 1К / tmain + 100К / tdetl, при этом 1 <= MaxUnflushedWrites <= 10 (он в коммитах измеряется). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 12:18:33 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
dimitrэто правда для вменяемых размеров базы, когда глубина индексов не зашкаливает. Иначе ахтунг в индексах очень быстро перевешивает все остальные критерии.А что именно там "ахтунгом" является ? Ну, вот есть индекс глубиной = 5 - и что в нём "такого страшного", отчего конкретно идут тормоза при добавлении ключей ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 12:22:47 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоидне вопрос, могу сделать всё в цикле, чтобы там автономная транзакция запихивала по 10 тыс в tmain + 1 млн в tdetl. Только ты скажи всё-таки: какие значения поставить для maxUnflushed* ? А то опять пальцем в небо ткну и время потеряю. попробуй настроить на коммит не реже чем раз в 1 млн записей, лучше меньше. Т.е. я бы предложил порции в 1К / tmain + 100К / tdetl, при этом 1 <= MaxUnflushedWrites <= 10 (он в коммитах измеряется).А вот этому: Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 12:25:39 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, MaxUnflushedWriteTime не трогай ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 12:28:57 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
dimitrпопробуй настроить на коммит не реже чем раз в 1 млн записей, лучше меньше. Т.е. я бы предложил порции в 1К / tmain + 100К / tdetl, при этом 1 <= MaxUnflushedWrites <= 10 (он в коммитах измеряется).Ффух... запустил, вобщем. И кажется мну, что очень скоро придется рестартовать с другим значением MaxUnflushedWrites Вот скрипт: Код: 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. Этот скрипт делает в одной автономной транзакции n_insa = 1000 вставок в TMAIN и n_insa * n_detl int = 100'000 вставок в TDETL. Параметр MaxUnflushedWrites установил равным 5. Число буферов - дефолтное, 2048. Параллельно в "мониторных" окнах запущены с логированием: iostat -x; iotop; vmstat. И хотя скрипт только-только начал работать, траблы повторяются (вернее, начались еще раньше, чем прежде): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Метод тыка какой-то идёт %-/ PS. Хреново, что трейс для такого скрипта вообще ничего не показывает: ХП для него деревянный ящик. Код: plaintext 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 00:34:54 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, вроде была идея сделать некую системную функцию которая могла бы писать в трейс пользовательские сообщения из PSQL. Это могло бы в ряде случаев упростить отладку. Но почему-то от неё отказались. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 08:57:56 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, а что в трейсе в моменты 00:25:18 и 00:32:20? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 09:09:02 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
В общем, докладаю. Затыки идут не только от ожидания сброса файлового кеша на диск (как я понимаю, linux-процессами flush и jdb2). Они возникают при любом MaxUnfluhedWrites, при передаче данных из кеша ФБ в кеш операционки: так показывает iotop . Логи iostat'a и vmstat'a для периодов, когда шли затыки, часто не содержат никаких "особых" значений, указывающих на повышенный IO, поэтому они тут не приводятся. Тест был такой (для maxUnflushedWrites=10): 1. в окнах 1..3 запускаются линух-мониторные утилиты с логированием вывода в соотв. файлы: iostat, vmstat, iotop Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 2. В окне 4 запускается скрипт huge_fil_at.sh ( '_at' = 'autonomous transaction': добавляет пачки записей в автономной транзакции), вызывающий isql и натравливающий на него .sql с заполнением данными. Особенность .sh в том, что по окончании работы isql он будет убивать мониторные процессы, запущенные в окнах 1...3. А сам же isql прекратится по эксепшену, как только время, затраченное на ввод 1'000 записей в TMAIN и 100'000 записей в TDETL, превысит порог = 15'000 ms (переменная 'MS_FOR_STOP'): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Ну, и собственно .sql-скрипт: huge_fil_at.sql Код: plaintext 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. В итоге всех прогонов (при ЛЮБОМ maxUnflushedWrites), всё заканчивалось примерно вот так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Как видим, последние два затыка были = 12 и 16 сек. Для затыка-1 лог iotop'a: iotop -o, 08:42:00...08:42:12 Код: plaintext 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. Для затыка-2 лог iotop'a: iotop -o, 08:43:48...08:44:04 Код: plaintext 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. Как видно по логам, при затыках 1) всегда что-то делалось потоком 26261 процесса firebird (это CACHE_WRITER ?) 2) иногда включался процесс jbd2/sda4-8. Для информации снял три бактрассы с ФБ (с интервалом ~45 сек) - они в аттаче. ЗЫ. файл базы при последнем затыке имел размер = 1.3 Гб. Его копирование занимает: 1) сразу после теста, когда база торчит в файловом кеше: Код: plaintext 1. 2. 3. 4. 2) при очистке файлового кеша: Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 09:40:33 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
dimitrа что в трейсе в моменты 00:25:18 и 00:32:20?не увидел этот вопрос вовремя, сейчас заново запущу, покажу результат. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 09:41:35 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Запустил еще раз этот тест, старушка мучалась около 2 минут. В аттаче логи: 1) трейса 2) вывода isql 3) iotop -o ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 09:53:36 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
а это... меня сейчас снова побьют за дурацкий вопрос, конечно, но... можно ли "распараллелить" работу передачи страниц в кеш операционки ? ну, то есть несколько cache_writer'ов запустить ? :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 09:57:32 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, нафига? Я так понял cache_write как раз делает запись в кэш при этом сериализует и синхронизирует необходимые действия (это собственно и есть общий кэш). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 10:04:21 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
ТаблоидЗапустил еще раз этот тест самые тяжелые случаи явно коррелируют: 2014-01-13T 09:44:32 .5470 (25802:0x7f4d6a34d188) COMMIT_TRANSACTION /var/db/fb30/huge_noext_at.fdb (ATT_8, SYSDBA:NONE, NONE, TCPv4:127.0.0.1) /opt/fb30trnk/bin/isql:27569 (TRA_61, READ_COMMITTED | REC_VERSION | NOWAIT | READ_WRITE) 3586 ms , 1 read(s), 1390 write(s), 1 fetch(es), 1 mark(s) 2014-01-13T 09:46:05 .9480 (25802:0x7f4d6a34d188) COMMIT_TRANSACTION /var/db/fb30/huge_noext_at.fdb (ATT_8, SYSDBA:NONE, NONE, TCPv4:127.0.0.1) /opt/fb30trnk/bin/isql:27569 (TRA_72, READ_COMMITTED | REC_VERSION | NOWAIT | READ_WRITE) 7399 ms , 1 read(s), 1176 write(s), 1 fetch(es), 1 mark(s) 2014-01-13T 09:47:48 .0370 (25802:0x7f4d6a34d188) COMMIT_TRANSACTION /var/db/fb30/huge_noext_at.fdb (ATT_8, SYSDBA:NONE, NONE, TCPv4:127.0.0.1) /opt/fb30trnk/bin/isql:27569 (TRA_83, READ_COMMITTED | REC_VERSION | NOWAIT | READ_WRITE) 11548 ms , 1 read(s), 1142 write(s), 1 fetch(es), 1 mark(s) 2014-01-13T 09:49:39 .2420 (25802:0x7f4d6a34d188) COMMIT_TRANSACTION /var/db/fb30/huge_noext_at.fdb (ATT_8, SYSDBA:NONE, NONE, TCPv4:127.0.0.1) /opt/fb30trnk/bin/isql:27569 (TRA_94, READ_COMMITTED | REC_VERSION | NOWAIT | READ_WRITE) 16435 ms , 1 read(s), 1126 write(s), 1 fetch(es), 1 mark(s) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 10:17:19 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
ТаблоидЛоги iostat'a и vmstat'a для периодов, когда шли затыки, часто не содержат никаких "особых" значений, указывающих на повышенный IO, поэтому они тут не приводятся. я бы ожидал, что колонка wa в выводе vmstat будет подскакивать в эти моменты ТаблоидКак видно по логам, при затыках 1) всегда что-то делалось потоком 26261 процесса firebird (это CACHE_WRITER ?) 26261 - коннект с инсертами, 26263 - кешрайтер ТаблоидДля информации снял три бактрассы с ФБ (с интервалом ~45 сек) - они в аттаче. два раза из трех кешрайтер пишет на диск ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 10:28:33 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоидЛоги iostat'a и vmstat'a для периодов, когда шли затыки, часто не содержат никаких "особых" значений, указывающих на повышенный IO, поэтому они тут не приводятся.я бы ожидал, что колонка wa в выводе vmstat будет подскакивать в эти моментыДа, ты прав; впрочем, значения % времени, пока проц ждал завершения IO, невелики: всего 7%. Лог isql: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Код: plaintext 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. 1) всегда что-то делалось потоком 26261 процесса firebird (это CACHE_WRITER ?) 26261 - коннект с инсертами , 26263 - кешрайтерТогда это еще сильнее интригует! Почему сами инсерты, а не их передача в файловый кеш линуха, грузят IO во всех затыках ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 13:42:32 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Симонов Дениснафига? Я так понял cache_write как раз делает запись в кэш при этом сериализует и синхронизирует необходимые действия (это собственно и есть общий кэш).Ну, это так, конечно: согласно принципу careful writes, он должен записывать страницы в строго определённом порядке. Ann Harrison - On disk consistency http://www.ibphoenix.com/resources/documents/design/doc_20 when the system writes a page that references another page, that other page must have been written previously in a state that supports the reference. Before writing a page that has a pointer from a record to its back version on another page, the system must have written that other page. Before writing out a new data page, the system must write out a version of a page information page (PIP) that shows the page is in use. The new data page has to be on disk, formatted and happy, before the table's pointer page that references the new page can be written. Inter-page relationships are handled in the code through a dependency graph in the cache manager. Before a page is written, the cache manager checks the graph and writes out all pages that page depends on. If a change will create a loop in the graph, the cache manager immediately writes as many pages as necessary to avoid the loop. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 13:55:17 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Симонов Денисвроде была идея сделать некую системную функцию которая могла бы писать в трейс пользовательские сообщения из PSQL. Это могло бы в ряде случаев упростить отладку. Но почему-то от неё отказались.Жаль, что это так. Неудобно во многих случаях. BTW, 0xFF: ты чего-нибудь начал сравнивать на тему page allocations (single vs extents) ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 13:56:33 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, тогда жди вот этого Vladyslav Khorsun2. Asyncronous and multi-block disk IO, prefetch of pages for natural scans and so on This feature is implemented for disk reads and i'm looking what can be done for disk writes too. Testing and some platform dependent adaptation is needed. (The implementation was tested briefly on Windows and Linux.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 13:58:42 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
ТаблоидBTW, 0xFF: ты чего-нибудь начал сравнивать на тему page allocations (single vs extents) ? Начал. Уже Владу отправлял результаты. Пока не совсем однозначно. Где-то выигрываем где то проигрываем. Думаю когда вот это "Asyncronous and multi-block disk IO, prefetch of pages for natural scans and so on" сделают преимущество будет значительно заметнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 14:01:52 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисТаблоидBTW, 0xFF: ты чего-нибудь начал сравнивать на тему page allocations (single vs extents) ?Пока не совсем однозначно. Где-то выигрываем где то проигрываем.а меня только выигрыши, причём на hasj-join'ах и простых селектах - самые большие (и даже есть на NL inner & outer - но там немного совсем). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 14:20:44 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
ТаблоидИ соотв-щий лог vmstat'a:Только я вижу us = 0 в эти моменты ? И сильно не нулевой bo насколько я понимаю us == CPU\user bo == blocks out ТаблоидПочему сами инсерты, а не их передача в файловый кеш линуха, грузят IO во всех затыках ?Опять пальцем в небо. Тебе же dimitr показал, что "страдает" коммит... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 14:31:58 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, я тебе позже отправлю свой тест в личку. Возможно причина в том, что ось Windows 7 по умолчанию не оптимизирована под сервисы, да и дисковая подсистема там обычная, никаких RAIDов нету. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 14:38:48 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Таблоида меня только выигрыши, причём на hasj-join'ах и простых селектах - самые большие (и даже есть на NL inner & outer - но там немного совсем). так и должно быть. По идее выигрыш должен быть везде где есть NATURAL скан ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 14:46:23 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Вести с полей. Изменил /etc/fstab, выключив барьеры на запись и признак обновления атрибутов файлов на каждый чих: Код: plaintext 1. 2. 3. 4. 5. Запустил с нуля isql + iotop + vmstat. Сначала был взлёт ракеты, очень долго итерации шли длительностью менее 1.5 сек. Одинг или два раза, впрочем, был затык на несколько десятков сек (около 20 сек вроде). Но вот после сотого ляма, кажись, тихо наступает Жо: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Однако, сейчас идёт заполнение БЕЗ автономных транзакций и с выключенным MaxunflushedWrites (что должны БЫЛО БЫ сбрасывать в кеш операционки фиксированные объёмы строк). Я дождусь его окончания, конечно, дабы затолкать в свой "лог успехов и поражений". После чего попробую с автономками (скрипт см выше). Если и там всё упрётся, то последнюю и опасную меру, буду добавлять в /etc/fstab атрибут выключения журнала ext4: data=writeback. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 20:11:50 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
И еще одна мысль вслух: https://www.kernel.org/doc/Documentation/filesystems/ext4.txt Write barriers enforce proper on-disk ordering of journal commits , making volatile disk write caches safe to use, at some performance penalty. If your disks are battery-backed in one way or another, disabling barriers may safely improve performance.Есть смутное ощущение, что поскольку ФБ сам выдаёт нужный порядок записи страниц (careful writes), при любом FW, то эти барьеры вообще нахрен не нужны, когда на хосте трудится только ФБ (а в бол-ве случаев именно так и происходит). И уж тем более при FW = OFF: раз мы сказали, что можем не ждать, когда ось запишет данные на ДИСК, то тем более по барабану, в какой последовательности она будет их туда записывать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 20:21:23 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Таблоидпо барабану, в какой последовательности она будет их туда записывать. Не совсем. Уже давным-давно на эти грабли нарывались все СУБД на NTFS: если уронить комп во время расширения файла, то в каталоге будет записан его новый размер, а новые страницы останутся пустыми (или наоборот: NTFS журнал откатывал расширение файла, оставляя ссылки на несуществующие страницы, уже не помню). Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 20:33:58 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, про барьеры я уже говорил http://www.sql.ru/forum/964856/linux-opciya-barrier-i-firebird и вот http://www.sql.ru/forum/895986/ext4-barrier-0-ili-1 со слов людей может быть до 3 раз хуже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 21:33:31 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
возвращаясь к старым гипотетическим баранам: ТаблоидСначала был взлёт ракеты, очень долго итерации шли длительностью менее 1.5 сек.пишем в кеш оси ТаблоидНо вот после сотого ляма, кажись, тихо наступает Жоось начинает сливать свой кеш на диск ТаблоидОднако, сейчас идёт заполнение БЕЗ автономных транзакций и с выключенным MaxunflushedWritesт.е. никаких принудительных сбросов кеша не было до тех пор, пока он не забился ЗЫ. напомнило копирование фильма на флешку под линухом - первые 4 гига пишем мегашустро, потом с черепашьей скоростью дописываем остатки, потом еще 10 минут отключаем устройство :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 21:43:43 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Интересно будет на idx_under_load базе проверить произв-сть DML, с и без барьеров. Там нет таких сумасшедших объёмов, всё наоборот как раз. Но зато коннектов будет штук 300. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 22:10:31 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
ТаблоидИзменил /etc/fstab, выключив барьеры на запись и признак обновления атрибутов файлов на каждый чих:На всякий: а файловую систему перемонтировал ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.01.2014, 00:22:03 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
hvladТаблоидИзменил /etc/fstab, выключив барьеры на запись и признак обновления атрибутов файлов на каждый чих:На всякий: а файловую систему перемонтировал ?я так понял, что достаточно просто отредактировать /etc/fstab и рестартануть хост. Что и было сделано. В итоге, сейчас: Код: plaintext 1. 2. 3. 4. Код: plaintext 1. Код: plaintext 1. И для верности глянул сюда: Код: plaintext 1. 2. 3. 4. 5. Вроде бы всё ОК ? ЗЫ. Скрипт всё равно в итоге стал ползти как черепаха. Сейчас только 171 млн сделано. Быстрее, конечно, чем в прошлый раз (начал его в 16:47), но всё равно не айс так долго ждать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.01.2014, 01:57:47 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
ТаблоидhvladНа всякий: а файловую систему перемонтировал ?я так понял, что достаточно просто отредактировать /etc/fstab и рестартануть хост. Что и было сделано.Ну, можно и рестартануть, если просто перемонтировать не получается :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.01.2014, 03:02:09 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
"Досчиталось" наконец. Но скрипело под занавес сильно: Код: plaintext 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. Так что буду таки пробовать с data=writeback. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.01.2014, 09:48:27 |
|
||
|
|

start [/forum/topic.php?all=1&fid=40&tid=1563982]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
267ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
| others: | 227ms |
| total: | 578ms |

| 0 / 0 |
