|
|
|
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
|
|||
|---|---|---|---|
|
#18+
hvladтак и запишем - безнадёжен.ну и ладно, записывай :-) Только я напоследок еще разок стрельну. Повторил тест для SC, заполнение таблицы с единственным полем, ts(id int), БЕЗ индексов, 95 млн строк. Буфер прежний, 16384. Сопоставил gstat -r итоговой базы: data pages = 1'171'352 Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Отношение числа записей в таблице к числу страниц в базе: 94879506 / 1171352 = 81. Отношение размера страницы к длине записи с учетом несжимаемого заголовка: 4096 / (16 + 8*4) = ~85. А это значит, что правило: "SC передает страницу в файловый кеш только, когда она заполнена" - соблюдается лишь при отсутствии индексов. Добавление индекса отменяет эту мантру к ЧМ: writes дёргается в 100500 раз чаще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2014, 23:18:52 |
|
||
|
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
|
|||
|---|---|---|---|
|
#18+
ТаблоидА это значит, что правило: "SC передает страницу в файловый кеш только, когда она заполнена" - соблюдается лишь при отсутствии индексов. Добавление индекса отменяет эту мантру к ЧМ: writes дёргается в 100500 раз чаще.Нет такого правила и быть не может. Ты его сам придумал, сам и опроверг. Хватит уже, кто-то может в эту чушь поверить ведь... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2014, 23:23:32 |
|
||
|
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
|
|||
|---|---|---|---|
|
#18+
hvladНет такого правила и быть не может. Ты его сам придумал, сам и опроверг. Хватит уже, кто-то может в эту чушь поверить ведь...посмотри аттач в здесь .мнупри вставке 6.3 млн строк в таблицу и два её индекса счетчик writes дёргался 3.7 млн раз. ЗЫ. Запустил 95 млн, но табличку эту, ts(x int), снабдил индексом. Пущай полетает, поглядим тогда в логи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2014, 23:38:09 |
|
||
|
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
|
|||
|---|---|---|---|
|
#18+
Таблоид, offtop, но не могу удержаться. Вместо того, чтобы генерить скрипт на 100500 итераций, воспользуйся пайпами. isql_shell.bat - запускатель для isql, но можно и непосредственно isql использовать Код: sql 1. 2. 3. 4. 5. 6. 7. 8. gen_cmd.bat - выводит все нужные команды в STDOUT Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. Run.bat - собственно запускает Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2014, 10:44:31 |
|
||
|
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
|
|||
|---|---|---|---|
|
#18+
hvladТаблоидА это значит, что правило: "SC передает страницу в файловый кеш только, когда она заполнена" - соблюдается лишь при отсутствии индексов. Добавление индекса отменяет эту мантру к ЧМ: writes дёргается в 100500 раз чаще.Нет такого правила и быть не может. Ты его сам придумал, сам и опроверг. Хватит уже, кто-то может в эту чушь поверить ведь...Нну-с, "продолжаем разговор" (С) :-) Сделал всё заново, на линухе. SuperClassic, buffers = 1024, база с единственной таблицей ts(x int). Вариант-1: добавление 95 млн строк в эту таблицу, когда для неё НЕТ индекса. Вариант-2: то же самое, но предварительно создан неуникальный индекс по полю `x`. Стейтмент добавления один и тот же: Код: plaintext gstat -r (после заполнения таблицы 95 млн строками, вариант БЕЗ индекса): Код: 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. Таким обр., на одной странице базы размещается 163 записи таблицы. За 1 сек до запуска стейтмента в другом окне был запущен запрос к mon$io_stats с регистрацией изменений mon$page_writes. В третьем окне был запущен трейс с регистрацией активности только рабочего коннекта, выполняющего вставки. ИТОГО. Вариант-1 (в аттаче - лист "ins-NON-index-buf-1024"): дельта значений в mon$io_stats.page_writes составила 572225, трейс показал сумму writes = 584422 (583403 по стейтменту и 1019 по коммиту). Это - очень хороший и пушистый результат: действительно видно, что SuperClassic выталкивал страницу в файловый кеш только когда она заполнена примерно 163 записями. Вариант-2 (в аттаче - лист "ins-INDEXED-buf-1024"): дельта значений в mon$io_stats.page_writes составила 62 794 292, трейс показал сумму writes = 62 795 289 (62794271 по стейтменту и 1018 по коммиту). Делим общее число записей в базе и (такое же) число ключей в индексе на 62 795 000: (94879506+94879506) / 62795000 - получаем результат около 3. То есть, на каждые три новых записи в таблице и столько же ключей в индексе - и две передачи в файловый кеш из страничного буфера. В где я ошибаюсь ? ЗЫ. сырые логи трейса и запроса к mon$-таблица, если надо, выложу на файлопомойку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2014, 14:59:42 |
|
||
|
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
|
|||
|---|---|---|---|
|
#18+
ТаблоидВ где я ошибаюсь ?Что ты хочешь доказать ? ps особенно умиляет сизифов труд по сопоставлению дельт в мониторинге это же МАРАЗМ в данном случае ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2014, 15:18:32 |
|
||
|
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
|
|||
|---|---|---|---|
|
#18+
hvladТаблоидВ где я ошибаюсь ?Что ты хочешь доказать ?я ничего не доказываю, просто результаты привожу. И хотел бы увидеть объяснение им. hvladps особенно умиляет сизифов труд по сопоставлению дельт в мониторинге это же МАРАЗМ в данном случаеОбоснуй, плз. Не понимаю, почему разглядывание дельт в mon$iostats стало маразмом в ДАННОМ варианте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2014, 15:32:14 |
|
||
|
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
|
|||
|---|---|---|---|
|
#18+
Таблоидя ничего не доказываю, просто результаты привожу.Это такое новое развлечение: ой, я выполнил запрос - смотрите все ! Ой, ещё один, смотрите же скорее ! ? ТаблоидИ хотел бы увидеть объяснение им.Тебе всё уже объяснили. Новых вопросов ты не задаёшь. Объяснения не понимаешь. Тебе не кажется, что кто-то ходит по кругу ? Таблоидhvladps особенно умиляет сизифов труд по сопоставлению дельт в мониторинге это же МАРАЗМ в данном случаеОбоснуй, плз. Не понимаю, почему разглядывание дельт в mon$iostats стало маразмом в ДАННОМ варианте.Потому что для одного запроса они не могут отличаться от итогового результата что в трейсе, что в isql. Ты везде ссылаешься на сумму этих дельт - так на кой они тебе (нет - нам тут!) вообще нужны ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2014, 15:39:39 |
|
||
|
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
|
|||
|---|---|---|---|
|
#18+
hvladЭто такое новое развлечение: ой, я выполнил запрос - смотрите все ! Ой, ещё один, смотрите же скорее !Да, ты угадал. Разумеется, это развлечение. Скорее смейтесь все, дабы я провалился от стыда и больше так не никогда делал. А смотреть в приаттаченные результаты - даже не вздумайте, там бред один. Ога. hvladдля одного запроса они не могут отличаться от итогового результата что в трейсе, что в isql. Ты везде ссылаешься на сумму этих дельт - так на кой они тебе (нет - нам тут!) вообще нужны ?Ты не читаешь то, что я спрашиваю. Я не сравниваю сумму дельт в mon$io_stats с трейсом! Они там вместе приведены просто для верности: проверяю сам себя, дабы избежать ошибки копипаста "не с того места". Меня интересует различие в отношении числа добавляемых записей к числу writes , когда вставки идут 1) без индексов, а затем 2) с индексом. Интерес вызван не праздным любопытством, а потерей большого кол-ва времени на ожидание результатов известных тебе скриптов. Для варианта вставки в не- индексированную таблицу это отношение (163) выглядит действительно так, как говорилось выше: SC передаёт страницу базы в файловый кеш только когда она будет почти вся заполнена. Для варианта вставки в таблицу + индекс отношение становится совершенно другим (около 3). ТЫ МОЖЕШЬ ОБЪЯСНИТЬ ЭТО РАЗЛИЧИЕ ? БОЛЬШЕ МНЕ НИЧЕГО НЕ НУЖНО В ЭТОМ ТОПИКЕ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2014, 16:08:59 |
|
||
|
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
|
|||
|---|---|---|---|
|
#18+
ТаблоидТы не читаешь то, что я спрашиваюА что ты спрашиваешь ? Что ?! Где вопрос ? Ты так заспамил свои же сообщения, что найти в них зерно - нереально. Например, какое отношение имеют твои последние N писем к твоей же теме топика ? ТаблоидМеня интересует различие в отношении числа добавляемых записей к числу writes Нет никакой прямой связи между этими двумя числами. Нет. НЕТ. НЕТ Так понятно ? У тебя страницы индекса пишутся и читаются многократно и это зависит от распределения ключей и очерёдности их появления в новых записях. И тебе на это неоднократно намекалось выше. Но ты вбил себе в голову только страницы данных и не видишь ничего вокруг... ТаблоидИнтерес вызван не праздным любопытством, а потерей большого кол-ва времени на ожидание результатов известных тебе скриптов.Я тебе уже сказал 100500 раз - ты не найдёшь эту причину в статистике ФБ. Ты читаешь то, что тебе пишут ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2014, 17:22:01 |
|
||
|
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
|
|||
|---|---|---|---|
|
#18+
hvladстраницы индекса пишутся и читаются многократно и это зависит от распределения ключей и очерёдности их появления в новых записях. И тебе на это неоднократно намекалось выше. Но ты вбил себе в голову только страницы данных и не видишь ничего вокруг...Я как раз вижу , что при записи именно индексных страниц показатель writes меняется, причём радикально. Надо добавить 95 млн записей и столько же ключей (пусть это будет в ДЕСЯТЬ раза больше инфы, чем без индекса), а writes увеличивается в 62795289 / 584422 - больше чем в 100 раз! Если ключ индекса состоит из одного int-поля и в таблицу добавляется три записи, то сколько новых индексных страниц должны добавиться ? Или (что скорее всего) сколько раз он должен обновить *одну и ту же* индексную страницу ? hvladты не найдёшь эту причину в статистике ФБ.Ты читаешь то, что тебе пишут ???Да, именно поэтому хочу выяснить это У ТЕБЯ, а не разглядывая статистику. Больше на Земном шаре всё равно никто не ответит. На каком языке еще надо объяснять мой вопрос, чтобы он был наконец-то понят ?... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2014, 18:05:23 |
|
||
|
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
|
|||
|---|---|---|---|
|
#18+
Таблоид, hvladстраницы индекса пишутся и читаются многократно и это зависит от распределения ключей и очерёдности их появления в новых записях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2014, 18:09:41 |
|
||
|
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
|
|||
|---|---|---|---|
|
#18+
Таблоид Или (что скорее всего) сколько раз он должен обновить *одну и ту же* индексную страницу ? при вставке в data pages перечитывать особо ничего не надо, а вот при обновлении индексов - надо. То есть, листовые страницы выпадают из кэша и их надо перечитывать, а еще и есть такое понятие как "расщепление страниц" b-tree при вставке ключей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2014, 18:19:30 |
|
||
|
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
|
|||
|---|---|---|---|
|
#18+
Таблоидсколько новых индексных страниц должны добавитьсяgstat -r ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2014, 18:26:51 |
|
||
|
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
|
|||
|---|---|---|---|
|
#18+
kdvлистовые страницы выпадают из кэша и их надо перечитывать, а еще и есть такое понятие как "расщепление страниц" b-tree при вставке ключей.hvladТаблоидсколько новых индексных страниц должны добавитьсяgstat -rВ общем, имею вот что сказать. 0) База создана со страницей = 8192, подключение имеет кеш = 16384 страницы. ФБ работает в режиме SuperClassic. FW = OFF. 1) в таблицу ts(x int) с единственным индексом по этому полю было предварительно добавлено ~95 млн записей; 2) в базе создана вьюха для просмотра снимка mon$-статистики: Код: 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. 4) снята статистика базы ПЕРЕД вставкой 100 строк: index ts_x: leaf buckets: 105200, nodes: 94879926 Код: 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. Далее: session #1. Код: plaintext session #2 Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. session #1 Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. session #2 Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Код: 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. leaf buckets: 105200, nodes: 94880026 Код: 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. Число страниц с данными не изменилось (582088). Сколько ФБ добавил новых ИНДЕКСНЫХ страниц, я по gstat -r не вижу. Пролейте свет кто-нить, как это можно определить. По трейсу и дельтам в mon$io_stats.page_writes получается, что: 1) либо ФБ изменил около 100 разных страниц на вставку 100 int-чисел. Но как такое может быть вообще ? 2) либо менялось меньшее число страниц с одними и теми же номерами, но они бесконца вытеснялись , оттого и writes ~100. Но это тоже выгляит нереальным, т.к. страничный кеш = 16384 - он покрывает все эти разности (fetshes2-fetches1 + writes2-writes2 + reads2-reads1) - как бык овцу, тут и считать ничего не надо. Если есть третий вариант, то это вопрос уже к корректности статистики. Такие вот делы. Дальше можете обзывать меня как хотите, посылдать проспаться, пинать ногами и прочая. Только объясните вышеприведенное, пож-ста. PS. Блин я этот тест никогда не забуду, чтоб его об тумбочку!.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2014, 21:21:55 |
|
||
|
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
|
|||
|---|---|---|---|
|
#18+
Таблоид1) либо ФБ изменил около 100 разных страниц на вставку 100 int-чисел.Дошло ! Наконец-то ! Пойду - напьюсь ТаблоидНо как такое может быть вообще ?Не, рано радуюсь :'( Разных ключей у тебя сколько ? Ответ - 65535 Листовых страниц в индексе сколько ? leaf buckets: 105200 Каждый ключ занимает сколько ? Более полутора страниц. Т.е. на каждой странице может быть 1 или 2 разных ключа. Какие ключи ты вставляешь ? Ответ - разные ! РАЗНЫЕ ! Куда ты их вставляешь ? В конец таблицы, т.е. recno будут максимальные. Так в какое место в цепочке дубликатов попадут новые ключи ? В конец каждой цепочки. Так сколько листовых страниц мы запачкаем сотней разных ключей ? А ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2014, 23:59:36 |
|
||
|
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
|
|||
|---|---|---|---|
|
#18+
hvladРазных ключей у тебя сколько ? Ответ - 65535 Листовых страниц в индексе сколько ? leaf buckets: 105200 Каждый ключ занимает сколько ? Более полутора страниц. Т.е. на каждой странице может быть 1 или 2 разных ключа.Ну-ка стой! Как это полторы страницы (12 КБ!) на 1 фигов ключик, который содержит в себе int-число, плюс номер записи туда прилепить, ну пусть еще и с "заголовком" каким-нибудь (или как там его звать) ?.. ЕЯПП, ты поделил 105200 на число уникальных ключей. А почему не на ОБЩЕЕ число ключей, которое 95 млн ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2014, 00:16:25 |
|
||
|
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
|
|||
|---|---|---|---|
|
#18+
ТаблоидhvladРазных ключей у тебя сколько ? Ответ - 65535 Листовых страниц в индексе сколько ? leaf buckets: 105200 Каждый ключ занимает сколько ? Более полутора страниц. Т.е. на каждой странице может быть 1 или 2 разных ключа.Ну-ка стой! Как это полторы страницы (12 КБ!) на 1 фигов ключик, который содержит в себе int-число, плюс номер записи туда прилепить, ну пусть еще и с "заголовком" каким-нибудь (или как там его звать) ?.. ЕЯПП, ты поделил 105200 на число уникальных ключей. А почему не на ОБЩЕЕ число ключей, которое 95 млн ?Пардон, забыл я про рисунок Анны в эпизодах, где индексы. С этим вариантом, когда дубликатов полно, вроде бы прояснилось. Остался вариант с уникальным индексом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2014, 00:29:26 |
|
||
|
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
|
|||
|---|---|---|---|
|
#18+
ТаблоидОстался вариант с уникальным индексом.Всё ясно. Дубликаты ключей - Мировое зло. Та же база+таблица, 95 млн строк, только залиты они были так: insert into ... select gen_id(g,1) from ... В итоге: 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. 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. trace Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2014, 01:01:15 |
|
||
|
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
|
|||
|---|---|---|---|
|
#18+
ТаблоидВсё ясно. Дубликаты ключей - Мировое зло.В твоём предыдущем тесте мировым злом был индекс на поле с guid - тут тоже дубликаты виноваты ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2014, 01:42:41 |
|
||
|
Вставка в индексир.таблицы: cache writer в 1 ед времени пишет в 20 раз > раб. потока
|
|||
|---|---|---|---|
|
#18+
Ты про тест, который tmain=2 млн и tdetl=200 млн строк ? там просто были неверно выбраны "гарабиты": надо было поменьше раз в 10 на каждую таблицу, и всё прошло бы без шума и пыли, за 3-4 часа :-) PS. насчет мирового зла - поправка: плохи не дубли, а большое кол-во цепочек, если они заканчиваются на разных страницах базы. Тогда действительно получается, что вставка 100 значений приводит к пачканию 300 страниц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2014, 08:46:26 |
|
||
|
|

start [/forum/topic.php?fid=40&gotonew=1&tid=1563962]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
182ms |
get topic data: |
7ms |
get first new msg: |
4ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
| others: | 222ms |
| total: | 494ms |

| 0 / 0 |
