|
Next - OIT > sweep_int: может ли НЕ начаться автостарт sweep'a при коннекте к такой базе ?
|
|||
---|---|---|---|
#18+
hi all Вот тут: https://yadi.sk/d/s_AAa-ASo3AKv -- архив с двумя базами ("sweep-ready.fd 0 " и "sweep-ready.fd 1 ", имеющими мусор и sweep interval = 100. Статистика по ним: sweep-ready.fd0 Код: 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.
"sweep-ready.fd1" Код: 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.
Для каждой из этих баз делаю следующее: 1) останавливаю ФБ 2) copy sweep-ready.fd0 sweep-ready-0.fdb // для второй - аналогично: copy sweep-ready.fd1 sweep-ready-1.fdb 3) стартую ФБ, обнуляю firebird.log 4) Вывод заголовка _до_ коннекта, коннект с единственной командой 'quit', вывод заголовка _после_, т.е.: * для первой базы: Код: plaintext
Код: plaintext
Ну так вот: 1) для первой базы такие записи в логе ФБ - будут, т.е. всё пучком: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
2) для второй базы записей в логе ФБ нет, но счетчики в её заголовке подвинутся и станут: Код: plaintext 1. 2. 3. 4.
Кто-нить может объяснить эту магию ? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.01.2016, 11:22 |
|
Next - OIT > sweep_int: может ли НЕ начаться автостарт sweep'a при коннекте к такой базе ?
|
|||
---|---|---|---|
#18+
Таблоид, в первой есть rolled back тр-ция, во второй - нет ... |
|||
:
Нравится:
Не нравится:
|
|||
31.01.2016, 11:57 |
|
Next - OIT > sweep_int: может ли НЕ начаться автостарт sweep'a при коннекте к такой базе ?
|
|||
---|---|---|---|
#18+
hvlad, это по заголовку базы как-то можно увидеть? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.01.2016, 12:22 |
|
Next - OIT > sweep_int: может ли НЕ начаться автостарт sweep'a при коннекте к такой базе ?
|
|||
---|---|---|---|
#18+
Таблоид, нет. Но можно в isql сделать connect show database commit show database если второй show database покажет такое же значение для OIT, как и первый, то это оно. Если свип за это время не пролетит, конечно :) ЗЫ я в твои БД не смотрел ... |
|||
:
Нравится:
Не нравится:
|
|||
31.01.2016, 12:32 |
|
Next - OIT > sweep_int: может ли НЕ начаться автостарт sweep'a при коннекте к такой базе ?
|
|||
---|---|---|---|
#18+
Спс. hvladЕсли свип за это время не пролетит, конечно :)Не пролетит: я все команды в одну строку затолкаю ) ... |
|||
:
Нравится:
Не нравится:
|
|||
31.01.2016, 12:38 |
|
Next - OIT > sweep_int: может ли НЕ начаться автостарт sweep'a при коннекте к такой базе ?
|
|||
---|---|---|---|
#18+
Так. Стоп! Уже не первый раз вижу и больше молчать не буду :) Создаем новую базу, ставим ей sweep_interval = 100. Заходим в isql и вводим там на выполнение скрипт: Код: 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.
Далее мы делаем в другом окне shutdown этой базы. С этого момента при переводе этой базы в онлайн первый же коннект к ней вызовет автосвип. Вопрос у мну в следующем: почему деятельность этого автосвипа по-разному отображается в логе трейса, когда он запущен с log_sweep = true ? Запускаем трейс. Переводим базу в онлайн и выполняем: echo quit; | isql host/port:наша_база_готовая_к_автосвипу Смотрим затем, что появляется в трейсе для SS /SC & CS. У меня получилось вот что: 1) для SuperServer 'a: sweep_start, sweep_progress, sweep_finish - т.е. всё логично и понятно: trace.log for SS Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
trace.log for SC Код: 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.
trace.log for Cs Код: 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.
Объясните кто-нить: 1) что за странный повтор sweep_progress'a в SC & CS ? 2) что там за недуг случился с Cs, от которого он оказался не в состоянии подвинуть OAT & OST вместе с OIT ? PS. WI-V3.0.0.32300; логи полностью - в аттаче ... |
|||
:
Нравится:
Не нравится:
|
|||
31.01.2016, 23:29 |
|
Next - OIT > sweep_int: может ли НЕ начаться автостарт sweep'a при коннекте к такой базе ?
|
|||
---|---|---|---|
#18+
ТаблоидОбъясните кто-нить: 1) что за странный повтор sweep_progress'a в SC & CS ?Включи print_perf - и нам расскажи ... |
|||
:
Нравится:
Не нравится:
|
|||
01.02.2016, 16:58 |
|
Next - OIT > sweep_int: может ли НЕ начаться автостарт sweep'a при коннекте к такой базе ?
|
|||
---|---|---|---|
#18+
Таблоид2) что там за недуг случился с Cs, от которого он оказался не в состоянии подвинуть OAT & OST вместе с OIT ?А что, кто-то другой их подвинул ? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.02.2016, 17:00 |
|
Next - OIT > sweep_int: может ли НЕ начаться автостарт sweep'a при коннекте к такой базе ?
|
|||
---|---|---|---|
#18+
hvladВключи print_perf - и нам расскажи Уже понял, спс. Рассказывать не буду :) hvladТаблоид2) что там за недуг случился с Cs, от которого он оказался не в состоянии подвинуть OAT & OST вместе с OIT ?А что, кто-то другой их подвинул ?Да, SS и SC - см их логи. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.02.2016, 18:31 |
|
Next - OIT > sweep_int: может ли НЕ начаться автостарт sweep'a при коннекте к такой базе ?
|
|||
---|---|---|---|
#18+
ТаблоидhvladА что, кто-то другой их подвинул ?Да, SS и SC - см их логи.Сам см. И нам тут пкж :) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.02.2016, 18:38 |
|
Next - OIT > sweep_int: может ли НЕ начаться автостарт sweep'a при коннекте к такой базе ?
|
|||
---|---|---|---|
#18+
hvlad, ну они там под спойлером были, разве не заметно ? Хорошо, вот вам всем прямой наводкой, в упор: Код: 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.
Код: 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.
Что скажете, товарищи ? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.02.2016, 18:44 |
|
Next - OIT > sweep_int: может ли НЕ начаться автостарт sweep'a при коннекте к такой базе ?
|
|||
---|---|---|---|
#18+
ТаблоидЧто скажете, товарищи ?Продолжаем разговор (ц) Покажи дельту для SS\SC\CS, т.е. насколько они продвинули OAT и OST. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.02.2016, 18:51 |
|
Next - OIT > sweep_int: может ли НЕ начаться автостарт sweep'a при коннекте к такой базе ?
|
|||
---|---|---|---|
#18+
тьфу, блин... глаза замылились ужо... :-[ но таки вопрос всё равно про Классик остался: а чего он не "поднял" OAT & OST до высот 160...161 в процессе молотьбы, как это произошло в SS & SC ? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.02.2016, 18:53 |
|
Next - OIT > sweep_int: может ли НЕ начаться автостарт sweep'a при коннекте к такой базе ?
|
|||
---|---|---|---|
#18+
Таблоид, вспомни, что я говорил на семинаре про значения OAT и OST и почему свип их не трогает. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.02.2016, 19:03 |
|
Next - OIT > sweep_int: может ли НЕ начаться автостарт sweep'a при коннекте к такой базе ?
|
|||
---|---|---|---|
#18+
ТаблоидЧто скажете, товарищи ? я уже много лет назад (разрабатывая IBAnalyst) нашел ситуацию, когда OIT может стать больше OST. Правда, чтобы OIT было больше OAT - не видел. Но допускаю такую возможность. см. http://www.ibase.ru/devinfo/summary.htm Когда ReadCommitted блокирует Oldest Snapshot hvladпро значения OAT и OST и почему свип их не трогает. а с какой стати, прости господи, sweep их должен (и может) "трогать"??? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2016, 00:37 |
|
Next - OIT > sweep_int: может ли НЕ начаться автостарт sweep'a при коннекте к такой базе ?
|
|||
---|---|---|---|
#18+
hvladвспомни, что я говорил на семинаре про значения OAT и OST и почему свип их не трогает.Это я буду осиливать на свежак. А сейчас, почтеннейшая публика, прошу внимания. "Следите за руками - никакого жульничества!.." 0. Стартуем ФБ, в двух режимах: SS & CS. 1. Создаём базу, делаем для неё "gfix -h 100", затем вводим на выполнение скрипт, от которого ISQL повесится: Код: 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.
3. Делаем шаги 1 и 2 в SS, затем в Cs (наверное, можно было бы и один раз сделать в любой арх-ре, но я решил всю эту "историю" разделить на всех этапах). Возвращаем базы в онлайн и копируем куда-нить для последующего многократного восстановления с них: Код: plaintext 1.
4. Делаем еще раз рестарт ФБ. 5. Начинаем эксперимент с SuperServer'ом , выполняя: Код: plaintext 1.
Счётчики gstat'a будут: Код: plaintext 1. 2. 3. 4.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8.
Нескладуха в OIT на 1, в OAT & OST - на 2, в Next - опять на 1. Т.е. свип записал счетчики в лог, но они всё-таки дёрнулись еще "кем-то", и это был _не_ gstat -h, который к базе коннект вообше не делает, а открывает её как файл. Ну да ладно, это SuperServer - там ведь лингер есть, да и вообще он базу не сразу отпускает после дисконнекта (60 или 70 сек держит файл, ЕМНИП). Как знать, может там что-то еще должно шевелиться после дисконнекта isql'я... :-) Интересно, однако, что если повторить вышеприведенные команды (copy ... и затем echo quit; | isql ... & gstat -h ...), то можем получить уже "нормальный" результат, при котором всё совпадает: Код: plaintext 1. 2. 3.
Код: plaintext 1. 2.
6. Начинаем эксперимент с Classic'ом , выполняя: Код: plaintext 1.
Код: plaintext 1. 2. 3.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8.
Повторяем всё опять с Классиком. * результат echo quit; | isql ... & gstat -h ...: Код: plaintext 1. 2. 3.
Код: plaintext 1. 2.
Всё хорошо, всё сходится ? Не будем наивными. Повторим команды из хистори и поиздеваемся еще немного :) И, раз: Код: plaintext 1. 2. 3.
Код: plaintext 1. 2.
И, два-с: Код: plaintext 1. 2. 3.
Код: plaintext 1. 2. 3.
А теперь объясните мне, плз: почему свип то ли "не успевает" увидеть реальные счетчики транзакций на момент своего окончания, то ли видит их, но "не все" ? Например, OAT & OST для Cs в сообщении "swep finished" - ну явно же старые остались. Хотя и не всегда, иногда "видит" и актуальные... вроде... PS. Обе базы, ready4sweep-sS.fdb & ready4sweep-Cs.fdb, подготовленные для автостарта свипа при первом же коннекте к ним, см. в аттаче. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2016, 01:47 |
|
Next - OIT > sweep_int: может ли НЕ начаться автостарт sweep'a при коннекте к такой базе ?
|
|||
---|---|---|---|
#18+
Таблоид, ломотно смотреть твои скрипты, может дело в том, что sweep кроме oit ничего больше "не двигает". И чтобы увидеть реальные счетчики надо стартануть транзакцию, хотя бы в isql. OST и OAT вверх двигает только старт новой транзакции (если они могут подвинуться). ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2016, 01:55 |
|
Next - OIT > sweep_int: может ли НЕ начаться автостарт sweep'a при коннекте к такой базе ?
|
|||
---|---|---|---|
#18+
kdvsweep кроме oit ничего больше "не двигает". И чтобы увидеть реальные счетчики надо стартануть транзакцию, хотя бы в isql. OST и OAT вверх двигает только старт новой транзакции (если они могут подвинуться).Хорошо, вот пример без isql'я (но нужно, чтобы на машине был установлен Python и дрова к ФБ - пакет "fdb"; база прописана в 'databases.conf' как алиас 'e30'). Делаю два .py-файлика: 1) для коннекта без транзакции к SuperServer'у (он слушает порт 3333; скрипт назван "test-sS.py"): Код: plaintext 1. 2. 3. 4.
2) для коннекта без транзакции к Classic'у (он слушает порт 3329; скрипт назван "test-Cs.py"): Код: plaintext 1. 2. 3.
Оба они при своём запуске ('python test-XX.py' должны выдать версию драйвера и тут же завершиться). Делаю рестарт ФБ (SS, CS), обнуляю firebird.log. Запускаю трейс с конфигом: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
И теперь делаю два прогона: 1) SuperServer: Код: plaintext
2) Classic: Код: plaintext
А дальше смотрю в логи трейса и ФБ. И вижу: 1) SuperServer: 1.1) firebird.log: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 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.
2) Classic: 2.1) firebird.log: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 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.
Однако, это не помешало OAT & OST сдвинуться, но только в SuperServer'e. Это значит, что в SS "кто-то" тихо дёрнул транзакцию, и в результате они сдвиинулись. Кроме того: значения счетчиков, в отличие от игр с isql'ем, выдаются стабильными, нету этих странностей с отличием значений в firebird.log (для 'sweep finish') и тем, что выдаёт после gstat -h. И еще. Classic показывает в трейсе сообщение 'sweep_progress' два раза - сначала для таблицы RDB$DATABASE, затем для "моей" таблицы TEST. Super - показывает 'sweep_progress' только 1 раз, для таблицы TEST; системные таблицы, насколько могу понять, свип в SS обходит стороной, что ле ? ЗЫ. ну да, смотреть на многабукаф в и мне в лом, но таки "странность" со счетчиками от этого никуда не денется :-) Ладно, кому интересно, тот найдёт 15-20 минут времени и прогонит у себя - я все шаги показал, базейки приаттачил. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2016, 09:21 |
|
Next - OIT > sweep_int: может ли НЕ начаться автостарт sweep'a при коннекте к такой базе ?
|
|||
---|---|---|---|
#18+
Таблоиду да ладно, это SuperServer - там ведь лингер есть, да и вообще он базу не сразу отпускает после дисконнекта (60 или 70 сек держит файл, ЕМНИП). никакого linger по умолчанию нет. Он по умолчанию стоит равным 60 секунд только у security3.fdb . Во всех других базах пока ты сам этот лингер не поставишь он не появится ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2016, 09:31 |
|
Next - OIT > sweep_int: может ли НЕ начаться автостарт sweep'a при коннекте к такой базе ?
|
|||
---|---|---|---|
#18+
Денис, ты бы проверил у себя все эти "выкладки". Особливо по Классику интересно: будет ли картина со счетчиками такая же, как я выше привёл, т.е. будут ли в конфиге ФБ для 'sweep finished' записаны значения OAT & OST, отличающиеся от реальных (выдаваемых gstat -h) ? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2016, 09:42 |
|
Next - OIT > sweep_int: может ли НЕ начаться автостарт sweep'a при коннекте к такой базе ?
|
|||
---|---|---|---|
#18+
Таблоид, пару предположений Свип для RDB$DATABASE запускается потому что в нём создаётся версия при DROP/CREATE TABLE (изменяется значение поля RDB$RELATION_ID). В супере есть ещё фоновая сборка мусора и она возможно успевает зачистить там всё до свипа. В тройке свип более хитёр и читает только страницы у которых swept flag = 0, т.е. те которые не вычистил сборщик мусора или не вычистил предыдущий свип. Я не сомневаюсь в приведённых тобой результатах, но не вижу причин для беспокойства ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2016, 09:56 |
|
Next - OIT > sweep_int: может ли НЕ начаться автостарт sweep'a при коннекте к такой базе ?
|
|||
---|---|---|---|
#18+
Таблоид, я тебе дам наводки, а ты сам разбирайся с этой чепухой: а) isql стартует 2 тр-ции, б) свип работает асинхронно в) свип стартует свою тр-цию г) фоновая сборка мусора стартует свою тр-цию (Денису плюс за догадку) Всё. Этого достаточно, чтобы всё объяснить. Правда смысла в этом - нулл в квадрате ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2016, 10:40 |
|
Next - OIT > sweep_int: может ли НЕ начаться автостарт sweep'a при коннекте к такой базе ?
|
|||
---|---|---|---|
#18+
hvladя тебе дам наводки, а ты сам разбирайся с этой чепухой: а) isql стартует 2 тр-ции, б) свип работает асинхронно в) свип стартует свою тр-цию г) фоновая сборка мусора стартует свою тр-цию (Денису плюс за догадку) Всё. Этого достаточно, чтобы всё объяснить. Правда смысла в этом - нулл в квадратеОно конечно верно, чепуха полная, да нулл в квадрате... только вот что происходит (следите снова за руками, никаких козырей у меня в рукавах нету :)): 1) создаем, как я выше говорил, два файлика: test-Cs.py и test-sS.py (они показаны выше); 2) создаем батник 'swptest.bat': Код: 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.
0) обнуление к ЧМ лога ФБ (который определит по входному параметру 'fb_arch' и внутренней переменной 'fbc', значение которой зависит от него); копирование файла базы-"эталона" (ready4sweep-sS.fdb или ready4sweep-CS.fdb) в файл базы для пыток ('E30.FDB') - см переменные db_source & db_target; 1) вызов gstat -h для db_target - т.е. для базы, которая "готова к сборке" мусора, но еще не стала объектом домогательств свипа; для SS это база "ready4sweep-sS.fdb", для CS - база "ready4sweep-CS.fdb" 2) вызов коннекта - и тут он может сделать одно из двух: 2.1) либо выполнить коннект силами ISQL'я (но тогда там и транзакции будут стартовать) 2.2) либо выполнить коннект силами Python'a - и тогда будет вызван "test-Cs.py" или же "test-sS.py" 3) вызов gstat -h для базы уже _после_ того, как управление вернулось из isql или python'a 4) показ непустых строк firebird.log'a (а там должны появиться строки-сообщения о сборке мусора). Ну так вот: когда этот батник дёргает Python для выполнения коннекта, то: 1) в SuperServer'e все три четчика (OIT, OAT & OST) будут продвинуты, но только для первого выполнения этого батника с момента рестарта ФБ ! Вот что будет на экране: Код: 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.
2) в Classic'e OIT (и только этот счетчик) будет продвинут при первом обращении к базе с момента рестарта ФБ: Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2016, 14:03 |
|
Next - OIT > sweep_int: может ли НЕ начаться автостарт sweep'a при коннекте к такой базе ?
|
|||
---|---|---|---|
#18+
И вот вам весь "пакет" для теста - см аттач. Настройте только под свои порты прослушки и каталоги ФБ. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2016, 14:05 |
|
|
start [/forum/topic.php?fid=40&fpage=65&tid=1562364]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
31ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
2ms |
others: | 259ms |
total: | 396ms |
0 / 0 |