|
|
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
FB 2.5. База FW=OFF В одной таблице 4 477 968 записей. нужно перекачать их в соседнюю таблицу похожей структуры. Решил проверить будет ли быстрее работа на ramdisk. Оказалось что на ramdisk экономия всего 24%. CREATE TABLE RCP_RAW_QLT ( RCPREP_ID ID, QLT_ID ID, QLT_VAL REAL_WNULL, VALUE_IN_DM REAL_WNULL, VALUE_NATIVE REAL_WNULL, VALUE_PREMIX REAL_WNULL, CONSTRAINT PK_RCP_RAW_QLT PRIMARY KEY (RCPREP_ID, QLT_ID), CONSTRAINT FK_RCP_RAW_QLT_QLT_ID FOREIGN KEY (QLT_ID) REFERENCES QM_DICT (QLT_ID), CONSTRAINT FK_RCP_RAW_QLT_RCPREP_ID FOREIGN KEY (RCPREP_ID) REFERENCES RCPREP (RCPREP_ID) ON DELETE CASCADE ); запрос insert into RCP_RAW_QLT (RCPREP_ID, QLT_ID, QLT_VAL, VALUE_NATIVE, VALUE_PREMIX) select RR.RCPREP_ID, RQ.QLT_ID, RQ.QLT_VAL, RQ.VALUE_NATIVE, RQ.VALUE_PREMIX from RCPREP RR join RCPRQLT RQ on RR.RCP_ID = RQ.RCP_ID and RR.RAW_ID = RQ.RAW_ID; RAM 2.23 минуты Query Time ------------------------------------------------ Prepare : 16,00 ms Execute : 142 195,00 ms Avg fetch time: 0,00 ms Memory ------------------------------------------------ Current: 262 186 112 Max : 264 527 168 Buffers: 60 480 Operations ------------------------------------------------ Read : 85 882 Writes : 135 689 Fetches: 136 491 901 Marks : 18 418 925 HDD 2.56 минуты Query Time ------------------------------------------------ Prepare : 16,00 ms Execute : 176 749,00 ms Avg fetch time: 0,00 ms Memory ------------------------------------------------ Current: 262 186 956 Max : 264 528 436 Buffers: 60 480 Operations ------------------------------------------------ Read : 85 881 Writes : 270 810 Fetches: 136 491 901 Marks : 18 486 521 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 13:56:35 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
bazilio77CREATE TABLE RCP_RAW_QLT ( RCPREP_ID ID, QLT_ID ID, QLT_VAL REAL_WNULL, VALUE_IN_DM REAL_WNULL, VALUE_NATIVE REAL_WNULL, VALUE_PREMIX REAL_WNULL, CONSTRAINT PK_RCP_RAW_QLT PRIMARY KEY (RCPREP_ID, QLT_ID), CONSTRAINT FK_RCP_RAW_QLT_QLT_ID FOREIGN KEY (QLT_ID) REFERENCES QM_DICT (QLT_ID), CONSTRAINT FK_RCP_RAW_QLT_RCPREP_ID FOREIGN KEY (RCPREP_ID) REFERENCES RCPREP (RCPREP_ID) ON DELETE CASCADE );Констрейнты на target-таблице можете временно drop, а после инсертов add ? если да, то попробуйте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 14:18:47 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
PS. Если констрейнты на target-таблице заглушать нельзя, покажите значение параметра TempCacheLimit. Судя по PK = (RCPREP _ID , QLT _ID ), для создания этого индекса "внутри" TempCacheLimit'a надо установить его не менее 4500000 * (20 + 4 +4 ) = ~126 Mb. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 14:25:19 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
ТаблоидPS. Если констрейнты на target-таблице заглушать нельзя, покажите значение параметра TempCacheLimit. Судя по PK = (RCPREP _ID , QLT _ID ), для создания этого индекса "внутри" TempCacheLimit'a надо установить его не менее 4500000 * (20 + 4 +4 ) = ~126 Mb. Спасибо за рекомендации. Но вопрос у меня чисто риторический. Задача не практическая, а тестовая. Почему выигрыш ramdiska на данной операции всего 25%. TempDir кстати тоже на ramdisk. Я ожидал большего. Получается в этой задаче мы упираемся в производительность самого сервера (чисто процессорная задача). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 18:08:17 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
bazilio77ТаблоидPS. Если констрейнты на target-таблице заглушать нельзя, покажите значение параметра TempCacheLimit. Судя по PK = (RCPREP _ID , QLT _ID ), для создания этого индекса "внутри" TempCacheLimit'a надо установить его не менее 4500000 * (20 + 4 +4 ) = ~126 Mb. Спасибо за рекомендации. Но вопрос у меня чисто риторический. Задача не практическая, а тестовая. Почему выигрыш ramdiska на данной операции всего 25%. TempDir кстати тоже на ramdisk. Я ожидал большего. Получается в этой задаче мы упираемся в производительность самого сервера (чисто процессорная задача).Вы не показали свой TempCacheLimit. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 18:17:09 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
ТаблоидВы не показали свой TempCacheLimit. Стандартный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 18:20:22 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
bazilio77ТаблоидВы не показали свой TempCacheLimit. Стандартный. Кстати при чем тут TempCacheLimit если и база и TempDir находятся на ramdiske ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 18:22:26 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
ТаблоидВы не показали свой TempCacheLimit. Сделал TempCacheLimit 250 Мб. Ничего не поменялось Время 2:21. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 18:31:30 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
bazilio77ТаблоидВы не показали свой TempCacheLimit. Сделал TempCacheLimit 250 Мб. Ничего не поменялось Время 2:21. А загрузка ядра процессора какая? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 18:32:17 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
bazilio77Стандартный.Он разный для SS (64 М) vs SC/CS (8M). bazilio77Кстати при чем тут TempCacheLimit если и база и TempDir находятся на ramdiskeКогда движку не хватает TempCacheLimit, он начинает выталкивать данные на диск, в каталог, заданный параметром TempDirs. ДАЖЕ ЕСЛИ В СИСТЕМЕ ЕЩЕ ПОЛНО ПАМЯТИ. В виндузе это видно просмотром соотв. каталога, в линухе - командой lsof -a +L1 <temp_folder_mount_point>: там появляются и растут времянки. Ну так вот: даже если параметр TempDirs указывает на ram-диск, обмен между "внутренней" памятью, которая была зарезервирована под TCL, и "наружней", настолько затратен, что там почти без разницы, жесткий это диск или ram. Совсем недавно я напоролся как раз на это, вот тынц . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 18:34:41 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
bazilio77Почему выигрыш ramdiska на данной операции всего 25% потому что FW=OFF ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 18:39:32 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
ТаблоидКогда движку не хватает TempCacheLimit, он начинает выталкивать данные на диск, в каталог, заданный параметром TempDirs. ДАЖЕ ЕСЛИ В СИСТЕМЕ ЕЩЕ ПОЛНО ПАМЯТИ. вот любишь ты по результатам пары экспериментов обобщенные выводы делать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 18:40:32 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоидКогда движку не хватает TempCacheLimit, он начинает выталкивать данные на диск, в каталог, заданный параметром TempDirs. ДАЖЕ ЕСЛИ В СИСТЕМЕ ЕЩЕ ПОЛНО ПАМЯТИ. вот любишь ты по результатам пары экспериментов обобщенные выводы делать...Но ведь ФБ не будет оттяпывать себе еще памяти под темпспейс, если TCL исчерпан ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 18:45:10 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Таблоид, не будет. Но пишет он в кеш файловой системы, так что СВОБОДНАЯ ПАМЯТЬ В СИСТЕМЕ ТАКИ БУДЕТ ИСПОЛЬЗОВАТЬСЯ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 18:55:28 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
dimitrне будет. Но пишет он в кеш файловой системы, так что СВОБОДНАЯ ПАМЯТЬ В СИСТЕМЕ ТАКИ БУДЕТ ИСПОЛЬЗОВАТЬСЯ.да, но я *сразу* после старта видел fb_* файлы в tempfs или в /tmp (когда TCL был мал) - это что получается, сама операционка их начинала записывать ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 19:00:07 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Таблоидда, но я *сразу* после старта видел fb_* файлы в tempfs или в /tmp (когда TCL был мал) - это что получается, сама операционка их начинала записывать ? они создаются сразу по исчерпании TCL, с нулевым размером. А вот писать туда ось начинает отнюдь не сразу. И уж тем более читает из своего кеша, а не с диска. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 19:06:50 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Резюме: FW=OFF при достаточном кэше нисколько не проигравыет ramdisk. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 21:13:23 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
bazilio77, во-первых, только при установленных в -1 параметрах MaxUnflushed* в конфиге. Во-вторых, все-таки проигрывает, пусть и немного. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 22:13:14 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
dimitrвсе-таки проигрывает, пусть и немного.на линухе при следующих изменённых параметрах конфига (NB: DefaultDBCachePages = 2048; арх-ра = SuperClassic; версия = LI-T3.0.0.30876): Код: plaintext 1. 2. 3. 4. - и вставке 5 млн строк в таблицу c последующим их удалением, картина следующая: DDL: Код: 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. log Код: 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. log Код: 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. Вставки выигрывают примерно на 16%. Удаления и подсчет числа записей, как видно, остались одинаковыми. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 01:38:38 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
0xFF. Когда вставка идёт в индексированную GTT, то было бы круто обновлять её индексы НЕ на каждой записи, а после окончания обработки "входного потока". Т.е. пока идёт заливка строк с 1-ой по 100499-ю - плевать на индексы, оставляем их в "несоответствующем" (новым данным) виде. /* Роллбак посередине случился - тем лучше, меньше откатывать надо (для gtt on commit preserve rows). Авария хоста - вообще по барабану, GTT и не должны при этом ничего сохранять. */ Когда же заканчивается добавление 100500-ой строки - обновляем все индексы на основе новых данных. Есть смутное сомнение, что так будет быстрее, чем сейчас. Да, я помню прекрасно, что "в GTT сделано почти всё также, как в fixed-таблицах", ибо времени было в обрез и проч. Это я просто высказал идею на будущее, чтобы в воздухе не растворилась... :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 01:48:24 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
ТаблоидКогда вставка идёт в индексированную GTT, то было бы круто обновлять её индексы НЕ на каждой записи, а после окончания обработки "входного потока". Т.е. пока идёт заливка строк с 1-ой по 100499-ю - плевать на индексы, оставляем их в "несоответствующем" (новым данным) виде.А что такое "входной поток" ? Где он начинается и где заканчивается ? И где найти ключи от всего только что вставленного "потока" ? Перечитывать 100500 записей ? Или копить всё в (резиновой) памяти по ходу вставок ? За контроль уникальности я даже не заикаюсь. При чём тут вообще GTT\не GTT ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 02:30:53 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Таблоид, насколько я в курсе, сейчас можно либо обновить один ключ, либо построить все ключи по всем записям, и пофиг это ГТТ или нет. для "отложенного до-индексирования" все равно пришлось бы целиком сканировать таблицу, проверяя, есть уже такие ключи, или нет. Хотя, по идее, "достроить" ключи быстрее, чем целиком перестроить весь индекс. Но такого механизма все равно (пока) нет. И он достаточно опасен. Например, в таблицу с 10 млн записей добавляем 1000 записей с "отложенным индексированием". В результате придется потом прочитать все 10млн записей, да еще и 10млн индексных чтений сделать. Так что спорная штука. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 02:33:05 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
hvladА что такое "входной поток" ? Где он начинается и где заканчивается ?эммм... ну вот когда движок начинает делать вот такое: Код: sql 1. - то разве он не "чувствует", когда заканчиваются данные из источника ? Трейс же имеет ключик log_statement_finish - он же "видит" каким-то образом этот самый "финиш"... hvladИ где найти ключи от всего только что вставленного "потока" ? Перечитывать 100500 записей ? Или копить всё в (резиновой) памяти по ходу вставок ?Даже если перечитывать (тест см ниже), будет ощутимый выигрыш. А если накапливать в памяти, так еще больше. Ибо чтобы исчерпать современные 16/32/64 Гб - это постараться надо. К тому же, накапливая ключи в памяти, можно "на ходу" понять, хватит ли имеющейся памяти или нет и прекратить это накопление, выполенив в итоге простое перечитывание. hvladЗа контроль уникальности я даже не заикаюсь.Я вёл речь только об insert'ах; delete & update тоже сюда подойдут. Merge - нет, тут безусловно надо контролировать сразу для каждой записи. Если же прога написана так, что делает insert'ы недопустимых дубликатов - разраб ССЗБ, пусть переписывает на merge. hvladПри чём тут вообще GTT\не GTT ???При том, что на них: 1) должен получиться наибольший выигрыш, т.к. их данные хранятся в /dev/shm (если настроить TempDirs как надо), там выключены careful writes; 2) в случае реализации такой фичи всякие ошибки (алгоритма этой реализации) будут менее болезненными. Ибо времянки. Результат теста предсказуем и не интересен, но пусть будет как аргумент. variant #1. Создаем GTT, напихиваем в неё данные (5 млн строк), а затем перечитываем её всю для построения индексов:] perfins_deferred_index_rebuild.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. 133 + 33 = 266 sec Код: 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. variant #2 . Создаем GTT и к ней сразу - те же самые индексы. Заливаем данные, заставляя движок обновлять на каждой записи 4 индекса: perfins_immediate_index_updating.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. 472 sec Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 13:13:13 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
kdvв таблицу с 10 млн записей добавляем 1000 записей с "отложенным индексированием". В результате придется потом прочитать все 10млн записей, да еще и 10млн индексных чтений сделать. Так что спорная штука.в идеале было бы накапливать добавленные ключики в памяти. Сейчас век дешёвых гига/терабайтов, времена поменялись уже лет 10 как бэ... :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 13:14:41 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Таблоид, времена поменялись, сервера уже давно многопользовательские, а ты все оптимизируешь исключительно для себя любимого. Выкинет твой волшебный инсерт все конкурентные сортировки в своп и придут по твою душу злые клиенты и/или админы. Будешь им рассказывать про новые времена и свой подход к дешевым гигабайтам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 13:24:15 |
|
||
|
|

start [/forum/topic.php?fid=40&fpage=103&tid=1563883]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
272ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 234ms |
| total: | 601ms |

| 0 / 0 |
