|
|
|
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
|
|||
|---|---|---|---|
|
#18+
Так-с. Продолжаем разговор :-) Имеется вот такой результатик поиска "случайного ID из диапазона" (при нагрузке 200 аттачей): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. И вот такая статистика базе и по таблице QDISTR на тот момент времени: Код: 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. Из ratio: 0.17 для индекса QDISTR_SND_ID следует, что примерно на каждом 6-м ключике движок должен прыгать на новую страницу данных. Трейс показывает, что всего было выполнено 106941 индексных чтений и при этом - 386497 фетчей (т.е. сумма количеств обращений к PP + DP + индексным страницам). На странице 16384 должно размещаться 16384 / 2,71 = ~6000 ключей. Как по этим цифиркам понять, сколько раз движок прыгал на новые страницы данных и, след., создавал себе random IO ? (хотя никаких reads'ов, как видим, не показано) PS. статистика по индексам, запротоколированная в логе теста (пересчет её делается регулярно каким-то из аттачей): TABIDXCURR_STATDONE_TIMESMS_MINMS_AVGMS_MAXLAST_DTSQDISTRPK_QDISTR1,4738E-636816350008.07.2014 23:05:55QDISTRQDISTR_DOC_SND1,53025E-536817457708.07.2014 23:05:55QDISTRQDISTR_SNDOP_RCVOP_SND_ID_DESC8,6322E-636817461008.07.2014 23:05:56QDISTR QDISTR_SND_ID 1,5298E-5 36816446108.07.2014 23:05:56QDISTRQDISTR_WARE_SND_OPTYPE0,000561482336817567008.07.2014 23:05:56 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2014, 23:33 |
|
||
|
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
|
|||
|---|---|---|---|
|
#18+
ТаблоидКак по этим цифиркам понять, сколько раз движок прыгал на новые страницы данных и, след., создавал себе random IO ? (хотя никаких reads'ов, как видим, не показано) ты сам себе ответил. I/O - это reads/writes. Нет чтений - нет никакого I/O, хоть рандомного, хоть последовательного. Сколько раз мне еще это надо написать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2014, 23:51 |
|
||
|
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
|
|||
|---|---|---|---|
|
#18+
Тогда безумно не хватает чего-то, что могло бы объяснить вот это:Таблоид Код: plaintext Причём, для их получения вовсе не надо запускать 200 аттачей. И 5-10 достаточно + подождать минут 5, пока они "в раж не войдут". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2014, 23:54 |
|
||
|
gstat -r, статистика по PK-индексу: total dup >> 0, max dup =2..3 Как это может быть ?
|
|||
|---|---|---|---|
|
#18+
во-первых, мне не нравится вьюха в плане. Она должна быть раскручена до таблиц. Высылай мне пример. Ну и 15 сек я бы тоже искал внутри вьюхи, ибо такой запрос не может генерить 106941 индексных чтений, там явно внутри что-то накручено. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2014, 00:06 |
|
||
|
|

start [/forum/topic.php?fid=40&gotonew=1&tid=1563479]: |
0ms |
get settings: |
7ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
191ms |
get topic data: |
8ms |
get first new msg: |
5ms |
get forum data: |
2ms |
get page messages: |
38ms |
get tp. blocked users: |
1ms |
| others: | 199ms |
| total: | 465ms |

| 0 / 0 |
