|
Такого я ещё не видел (SYSIBM.SYSDUMMY1, DB2/NT64 11.5.6.0, DB2/LINUXX8664 11.5.5.0)
|
|||
---|---|---|---|
#18+
Скачал https://www.hammerdb.com/ и сел развлекаться с DB2/NT64 11.5.6.0. По монитору вижу запросы наподобие Код: sql 1. 2.
Поудивлялся. Решил удостовериться, написав скрипт вручную. И получил... Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
С другой базой всё нормально: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 18:13 |
|
Такого я ещё не видел (SYSIBM.SYSDUMMY1, DB2/NT64 11.5.6.0, DB2/LINUXX8664 11.5.5.0)
|
|||
---|---|---|---|
#18+
На свежесозданной базе такого нет, HammerDB что-то меняет. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 18:26 |
|
Такого я ещё не видел (SYSIBM.SYSDUMMY1, DB2/NT64 11.5.6.0, DB2/LINUXX8664 11.5.5.0)
|
|||
---|---|---|---|
#18+
Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
И это происходит в результате работы HammerDB (DB2 -> TPROC-C-> Virual User -> Run), но не при помощи смены параметров DB или DBM. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
(VVM.DBCFG - сохранённые данные до запуска HammerDB) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 19:48 |
|
Такого я ещё не видел (SYSIBM.SYSDUMMY1, DB2/NT64 11.5.6.0, DB2/LINUXX8664 11.5.5.0)
|
|||
---|---|---|---|
#18+
Victor Metelitsa, Код: sql 1. 2. 3.
? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2021, 21:28 |
|
Такого я ещё не видел (SYSIBM.SYSDUMMY1, DB2/NT64 11.5.6.0, DB2/LINUXX8664 11.5.5.0)
|
|||
---|---|---|---|
#18+
Тьма таких сообщений. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
Иногда бывает такое: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Развлекаюсь с СУБД на старенькой 4-ядерной (без Hyperthreading, но с тремя SSD) машинке с 16 гигами RAM в качестве сервера. (Сейчас) там Windows. Autopilot Sequence 1 2 4 8 12 16 20 24. Для DB2 пик пока достигается на 8 юзерах, дальше производительность падает. База, транзакционные логи и место под архив транзакционных логов - на разных SSD. Тест оставляет немало вопросов. Сперва меня вообще удивило, что у большей части таблиц нет ключей. Но там используется оптимизация. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
По мне, это в некотором смысле смахивает на жульничество (но победить других контестантов на той же машине всё равно не помогает). Что более важно, foreign keys я не обнаружил, а по спецификации TPC-C они должны быть. Возможно, если я их сделаю, то "The active transaction log is being held by dirty pages" уйдёт (в смысле, если процессор будет занят ещё и проверкой foreign keys, то transaction log будет менее занят и ему будет больше времени на очистку. Ещё странность Код: sql 1. 2. 3. 4. 5.
С проблемой выше я пока не разобрался - во-первых, много отвлекался на другие темы, и, во-вторых, хотя формально исходники hammerDb есть, разбираться в них очень тяжко. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2021, 10:04 |
|
Такого я ещё не видел (SYSIBM.SYSDUMMY1, DB2/NT64 11.5.6.0, DB2/LINUXX8664 11.5.5.0)
|
|||
---|---|---|---|
#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. 27. 28. 29. 30. 31. 32. 33.
1. Когда в таблице ORGANIZE BY ROW USING KEY SEQUENCE, foreign key другой таблицы может на это ссылаться, не нужно явным образом описывать primary или unique key (что удобно). 2. Транзакции в TPC-C построены таким образом, что сотая часть должна заканчиваться rollback'ом. Поскольку foreign keys не были заранее прописаны, инвалидные данные попали в ORDER_LINE. Но пока непонятно, будет ли hammerDB работать вообще, если я foreign keys создам до тестов. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2021, 16:33 |
|
Такого я ещё не видел (SYSIBM.SYSDUMMY1, DB2/NT64 11.5.6.0, DB2/LINUXX8664 11.5.5.0)
|
|||
---|---|---|---|
#18+
На "2." в прелыдущем сообщении - да, работает. Нашёл в Сети полезную PDF-ку - DemystifyingLoggingAndRecoveryLatest.pdf. В частности, DemystifyingLoggingAndRecoveryLatest– ADM1822W The active transaction log is being held by dirty pages. Database performance may be impacted. The rate at which the database work load is generating dirty pages has exceeded the rate at which the page-cleaner agents are writing dirty pages to disk. Dirty pages that have not yet been written to disk are holding the transaction log. – Corrective action: Decrease the value of the PAGE_AGE_TRGT_MCR and PAGE_AGE_TRGT_GCR Имея в виду, что DemystifyingLoggingAndRecoveryLatest – SOFTMAX deprecated as of DB2 10.5 – SOFTMAX=0 means use new parameters • Set by default for new databases created in DB2 10.5 • Old value maintained for upgraded databases PAGE_AGE_TRGT_MCR – Target duration (in seconds) for changed pages to be kept in the local buffer pool before being persisted to disk (or to the group buffer pool (GBP) in pureScale) – Applicable to both non-pureScale and pureScale environments PAGE_AGE_TRGT_GCR – Target duration (in seconds) for changed pages to be kept in the GBP before being persisted (cast out) to disk – Applicable to pureScale environments only ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2021, 09:35 |
|
Такого я ещё не видел (SYSIBM.SYSDUMMY1, DB2/NT64 11.5.6.0, DB2/LINUXX8664 11.5.5.0)
|
|||
---|---|---|---|
#18+
Explanation: The rate at which the database work load is generating dirty pages has exceeded the rate at which the page-cleaner agents are writing dirty pages to disk. Dirty pages that have not yet been written to disk are holding the transaction log. User response: 1. Reduce the database work load, if possible. 2. If this problem persists, take the following action: * Decrease the value of the PAGE_AGE_TRGT_MCR and PAGE_AGE_TRGT_GCR database configuration parameters * Increase the value of the NUM_IOCLEANERS database configuration parameter ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2021, 09:38 |
|
Такого я ещё не видел (SYSIBM.SYSDUMMY1, DB2/NT64 11.5.6.0, DB2/LINUXX8664 11.5.5.0)
|
|||
---|---|---|---|
#18+
Mark Barinstein Victor Metelitsa, Код: sql 1. 2. 3.
? А-а-а-а!!! Я только что заметил это письмо, и даже, видя многократно Код: plsql 1. 2. 3. 4. 5.
не задумался. Да, это оно. Правда, смысл по две минуты подряд бомбардировать сервер запросами Код: plsql 1. 2.
всё равно не очень понятен. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2021, 14:38 |
|
Такого я ещё не видел (SYSIBM.SYSDUMMY1, DB2/NT64 11.5.6.0, DB2/LINUXX8664 11.5.5.0)
|
|||
---|---|---|---|
#18+
Victor Metelitsa Explanation: The rate at which the database work load is generating dirty pages has exceeded the rate at which the page-cleaner agents are writing dirty pages to disk. Dirty pages that have not yet been written to disk are holding the transaction log. User response: 1. Reduce the database work load, if possible. 2. If this problem persists, take the following action: * Decrease the value of the PAGE_AGE_TRGT_MCR and PAGE_AGE_TRGT_GCR database configuration parameters * Increase the value of the NUM_IOCLEANERS database configuration parameter Ну, в общем-то из стандартного описания предупреждения в документации и так понятно, что page cleaner'ы не успевают делать свою работу. Заставить их шевелиться быстрее можно одним из 2-х способов, которые приводятся в описании сообщения: - увеличить их количество (NUM_IOCLEANERS) - заставить их работать более агрессивно (уменьшая либо SOFTMAX, которая deprecated, либо новую PAGE_AGE_TRGT_MCR - время жизни грязной страницы в памяти) ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2021, 15:49 |
|
Такого я ещё не видел (SYSIBM.SYSDUMMY1, DB2/NT64 11.5.6.0, DB2/LINUXX8664 11.5.5.0)
|
|||
---|---|---|---|
#18+
ADM1822W не проблема. "Cannot honor the conditional request" - DIA8531C A memory access error has occurred. Моря таких сообщений. Вот это меня смущает. Я подозреваю, что это может быть как-то связано с причиной, по которой не удаётся догнать контестантов. После 8 виртуальных юзеров производительность начинает падать... Юзера эти, конечно, страшные - каждый стоит больше сотни реальных, я подозреваю. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2021, 20:03 |
|
Такого я ещё не видел (SYSIBM.SYSDUMMY1, DB2/NT64 11.5.6.0, DB2/LINUXX8664 11.5.5.0)
|
|||
---|---|---|---|
#18+
Переключился на Linux. "Cannot honor the conditional request" там тоже лезут, но график другой. Но, быть может, это с одной SSD-шкой появились проблемы - она стала нагружаться на 100%, чего под виндой не наблюдалось. Стал играть с hugepages. Доигрался: поставил большой (db) параметр в database_memory и теперь к базе нельзя подключиться. SQL1643C The database manager failed to allocate shared memory because the database manager instance memory limit has been reached. Что самое восхитительное, чтобы параметр изменить, надо обязательно подключиться к базе, но это невозможно. Оверрайдить буферный пул, естественно, бесполезно. Да, есть и такой (dbm) параметр - instance_memory. Но даже на максимум его ставить бесполезно. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.01.2022, 23:39 |
|
Такого я ещё не видел (SYSIBM.SYSDUMMY1, DB2/NT64 11.5.6.0, DB2/LINUXX8664 11.5.5.0)
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
01.01.2022, 23:57 |
|
Такого я ещё не видел (SYSIBM.SYSDUMMY1, DB2/NT64 11.5.6.0, DB2/LINUXX8664 11.5.5.0)
|
|||
---|---|---|---|
#18+
Victor Metelitsa поставил большой (db) параметр в database_memory и теперь к базе нельзя подключиться. SQL1643C The database manager failed to allocate shared memory because the database manager instance memory limit has been reached. Что самое восхитительное, чтобы параметр изменить, надо обязательно подключиться к базе, но это невозможно. Оверрайдить буферный пул, естественно, бесполезно. Для изменения параметра базы надо к ней подключаться? А что, команда ниже выдаёт какую-то ошибку на вашей базе с именем mydb ? Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
02.01.2022, 11:25 |
|
Такого я ещё не видел (SYSIBM.SYSDUMMY1, DB2/NT64 11.5.6.0, DB2/LINUXX8664 11.5.5.0)
|
|||
---|---|---|---|
#18+
Я там далее написал "Упс". По синтаксису подключаться не обязательно. Но я, как часто бывает, поторопился и отправил сообщение, которое не стоило отправлять. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.01.2022, 14:54 |
|
Такого я ещё не видел (SYSIBM.SYSDUMMY1, DB2/NT64 11.5.6.0, DB2/LINUXX8664 11.5.5.0)
|
|||
---|---|---|---|
#18+
Как-то не очень нравится мне работа с большими страницами. Ораклю как скажешь "использовать столько-то для SGA", так он и хапает при старте всё, потом делит этот кусок на ломтики по своему усмотрению. Тут же я задаю database_memory, потом смотрю на /proc/meminfo: во-первых, резервирует, но большую часть не пытается использовать (а ведь могла бы всё буферному пулу отдать, например), а, во-вторых, цифры резерва меняются со временем. Под Linux'ом это едва ли проблема, если "чужих" программ нет. Но под Windows такое поведение внушает тревогу, потому что там угрожали фрагментацией, после которой большестраничная память могла быть и не выделена в какой-то момент. А такое ли поведение под Windows - непонятно, до меня так и не дошло, куда смотреть использование больших страниц. (просто добавляю db2admin право на lock pages, dbset db2_large_mem=db, а потом не знаю, использует ли). ... |
|||
:
Нравится:
Не нравится:
|
|||
02.01.2022, 15:09 |
|
Такого я ещё не видел (SYSIBM.SYSDUMMY1, DB2/NT64 11.5.6.0, DB2/LINUXX8664 11.5.5.0)
|
|||
---|---|---|---|
#18+
Сеть всё-таки довольно сильно влияет: 7:10 сеть:локально (для одного коннекта). Даже без сети под линухом не грузится больше двух ядер, хотя коннектов до 24; весьма активных коннектов причём. SSD нагружены не на 100%, а "так" - 85-90. Что-то мешает, но не приходит в голову, что. Вроде бы Developer был 4-мя ядрами ограничен, параметров конфигурации подходящих тоже не припомню. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.01.2022, 20:10 |
|
Такого я ещё не видел (SYSIBM.SYSDUMMY1, DB2/NT64 11.5.6.0, DB2/LINUXX8664 11.5.5.0)
|
|||
---|---|---|---|
#18+
Victor Metelitsa "Cannot honor the conditional request" - DIA8531C A memory access error has occurred. Моря таких сообщений. Это, например, может быть: IT38476: YOU MIGHT SEE LOT OF SQLBPROCESSDSTACK MESSAGES IN DB2DIAG.LOG , которая исправлена в 11.5.7.0. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2022, 14:52 |
|
Такого я ещё не видел (SYSIBM.SYSDUMMY1, DB2/NT64 11.5.6.0, DB2/LINUXX8664 11.5.5.0)
|
|||
---|---|---|---|
#18+
Ну, так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
Ещё пара занятных моментов. * С DB2_4K_DEVICE_SUPPORT=ON у меня DB2/L добилась своего рекорда в одноюзерном режиме. К четырём же юзерам результаты выровнялись. * Под виндами у меня результаты были гораздо лучше. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2022, 16:29 |
|
Такого я ещё не видел (SYSIBM.SYSDUMMY1, DB2/NT64 11.5.6.0, DB2/LINUXX8664 11.5.5.0)
|
|||
---|---|---|---|
#18+
db2diag.log на системном SSD, так что слишком частая генерация сообщений ssd с данными и ssd с транзакционными логами не грузила. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2022, 16:35 |
|
Такого я ещё не видел (SYSIBM.SYSDUMMY1, DB2/NT64 11.5.6.0, DB2/LINUXX8664 11.5.5.0)
|
|||
---|---|---|---|
#18+
latch contention = насколько я ничего не понимаю, latch'и было модно делать на spinlock'ах, т.е., ждать - не висеть на семафоре, а крутиться в цикле (и кушать CPU). ... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2022, 16:38 |
|
Такого я ещё не видел (SYSIBM.SYSDUMMY1, DB2/NT64 11.5.6.0, DB2/LINUXX8664 11.5.5.0)
|
|||
---|---|---|---|
#18+
Victor Metelitsa Где бутылочное горлышко - там же должно быть 100%? Необязательно, конечно. В смысле, одна нить наверняка не нагрузит что-то на 100%. Хотя есть надежда, что много нитей нагрузят что-то близко к 100%, но это при условии, что нагрузка от них хаотична. Но что происходит с DB2, когда количество активных клиентов растёт, но количество транзакций в секунду падает? Вот для 8 юзеров: Код: 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. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264. 265. 266. 267. 268. 269. 270. 271. 272. 273. 274. 275. 276. 277. 278. 279. 280. 281.
Вот для 24-х: Код: 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. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264. 265. 266. 267. 268. 269. 270. 271. 272. 273. 274. 275. 276. 277. 278. 279. 280. 281. 282. 283. 284. 285. 286. 287. 288. 289. 290. 291. 292. 293. 294. 295. 296.
... |
|||
:
Нравится:
Не нравится:
|
|||
07.01.2022, 18:54 |
|
Такого я ещё не видел (SYSIBM.SYSDUMMY1, DB2/NT64 11.5.6.0, DB2/LINUXX8664 11.5.5.0)
|
|||
---|---|---|---|
#18+
11.5.7 (фикспак с пробной лицензией) = сообщений "Cannot honor the conditional request" нет, но и принципиальной разницы нет. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8.
%system, правда, уж очень большой. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.01.2022, 14:52 |
|
Такого я ещё не видел (SYSIBM.SYSDUMMY1, DB2/NT64 11.5.6.0, DB2/LINUXX8664 11.5.5.0)
|
|||
---|---|---|---|
#18+
Я стал делать свой вариант HammerDB (Java, многонитевый JDBC), и он даже как-то работает и делает то, что я от него хотел, хотя едва ли годится для того, чтобы предоставить широкой публике. Но теперь я понял, что нужны "микро"-бенчмарки. Нагрузка a-la TPC-C смешанная, но для лучшего понимания происходящего нужно раздельно исследовать вещи (к примеру, только вставки или только рандомные апдейты). По дороге я заметил любопытную вещь: Код: plsql 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.
У HammerDB в варианте для DB2 многие таблицы созданы с ORGANIZE BY ROW USING KEY SEQUENCE. Если вспомнить, как это устроено, то да, с моей точки зрения это смахивает на жульничество. Хотя условия теста TPC-C и позволяют, но в реальной базе вы очень редко знаете, сколько строк будет в таблице. Кроме того, архивация логов должна быть включена, mincommit = 1, внешние ключи на месте, никаких real вместо decimal(4,4) и т.д. Так вот, "нормальный" вариант (без USING KEY SEQUENCE) у меня оказался заметно быстрее. На одном юзере чуть быстрее, на 24 где-то 7:5 (по количеству выполненых транзакций). ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2022, 18:33 |
|
|
start [/forum/topic.php?fid=43&tid=1600090]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
26ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
others: | 19ms |
total: | 140ms |
0 / 0 |