|
|
|
Помогите с настройками пожалуйста. 64 Гб рамы и тормозит.
|
|||
|---|---|---|---|
|
#18+
Пытаюсь заставить работать постгре без тормозов. Индексы на всех полях, по которым делается поиск. Сценарий: таблица с >2 млн. записей, в которую вставляется примерно 300-500 тыс. строк в сутки, в 60 потоков. Бинарных данных нет, есть json и служебная инфа, есть ещё несколько небольших таблиц (10-100 записей) в которых эти же потоки постоянно обновляют статус операций и счётчики (select/update). Что я хочу понять: 1. Почему тормозит. Чухом нюю, что можно быстрее, но может я не прав? 2. Может быть можно как-то оптимизировать запрос? Ускорят ли процесс вьюхи? Версия 9.5.2, в системе 64 Гб ОЗУ, linux 64бит ядро 4.5.1. Вот такой запрос может занимать до минуты (это статистика, дёргаю раз в пять минут): Код: plsql 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. И вот схема базы - сделал дамп, почистил руками. Код: 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. 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2016, 08:35 |
|
||
|
Помогите с настройками пожалуйста. 64 Гб рамы и тормозит.
|
|||
|---|---|---|---|
|
#18+
balak, 1)Сначала вам нужен графический мониторинг чтобы понять где и чего вам не хватает (дисков? памяти? cpu? сети?) 2)с конкретным проблемным запросом вам надо сделать explain (analyze, costs, buffers, timing) ... и прислать результаты чтобы вам что то подсказали. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2016, 10:54 |
|
||
|
Помогите с настройками пожалуйста. 64 Гб рамы и тормозит.
|
|||
|---|---|---|---|
|
#18+
balak Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Ну зачем же 7 раз устраивать сканирование по одной и той же таблице? Можно же это делать за один проход, считая поля через CASE. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2016, 16:05 |
|
||
|
Помогите с настройками пожалуйста. 64 Гб рамы и тормозит.
|
|||
|---|---|---|---|
|
#18+
ChA, Большое спасибо, я не знал про CASE После получаса перебора различных комбинаций получилось: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 8.258155116 сек Слегка коробит от прямого перебора 1 или 0, но никак не придумал как воткнуть count(). Код: sql 1. Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2016, 22:19 |
|
||
|
Помогите с настройками пожалуйста. 64 Гб рамы и тормозит.
|
|||
|---|---|---|---|
|
#18+
balak, Подстроку "ELSE 0 " можно смело удалять, суммируются только не-NULL значения. Вместо SUM можно было написать COUNT, COUNT(выражение), опять же, считает количество не-NULL значений. Впрочем, это по смыслу практически не отличается от суммирования единиц, так что это чисто на ваше усмотрение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2016, 23:11 |
|
||
|
Помогите с настройками пожалуйста. 64 Гб рамы и тормозит.
|
|||
|---|---|---|---|
|
#18+
balakСлегка коробит от прямого перебора 1 или 0, но никак не придумал как воткнуть count(). Посмотрите в сторону 4.2. Value Expressions раздел - 4.2.7. Aggregate Expressions aggregate_name ( * ) [ FILTER ( WHERE filter_clause ) ] Но я в вашем случае прислушался бы к совету Максима. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2016, 21:08 |
|
||
|
Помогите с настройками пожалуйста. 64 Гб рамы и тормозит.
|
|||
|---|---|---|---|
|
#18+
Rhim, спасибо за подсказку. Посмотрю на агрегатные функции. Я понимаю, что Максим, по большому счёту, прав. Но если бы я знал что запускать и куда смотреть, я бы здесь не спрашивал (= Кроме того - времени на процесс изучения у меня немного, вот трачу по часу в день пытаясь что-то понять. Пока что мне удалось ещё в два раза ускорить запросы и сильно повысить отзывчивость постгреса. Я обнаружил, что (ruby) гемы pg и activerecord, которыми я пользуюсь в разных скриптах - все ходят через tcp 127.0.0.1. Срочно перевёл все подключения на pipe. Вот данные по нагрузке и отчёт из pgadmin прикреплён, но что на самом деле означают многие из тамошних цифр я не понимаю. Заодно в чётвертый раз переписал настройки. $ iostat -c -d Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. postgresql.conf Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.05.2016, 17:25 |
|
||
|
Помогите с настройками пожалуйста. 64 Гб рамы и тормозит.
|
|||
|---|---|---|---|
|
#18+
На всякий случай, для тех, кто после меня. Подключение ruby pg activerecord на локальный сокет postgresql, вместо tcp/ip 127.0.0.1 Для того, чтобы подключение было на pipe - в парметрах как PG.connect так и ActiveRecord.establish_connection надо удалить (или не указать) параметры: Код: ruby 1. Причем если речь идёт о автоподключении ActiveRecord с настройками из RAILS_ENV, то эти ключи надо удалить из config/database.yml Либо отдавать параметры насильно - Код: ruby 1. 2. 3. Я проверял результат так: Код: plaintext Код: ruby 1. затем смотрю в pgadmin /браузер объектов/подключение, справа во вкладке "Статистика" отображается этот запрос и в колонке "Клиент" - "локальный pipe". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.05.2016, 17:40 |
|
||
|
Помогите с настройками пожалуйста. 64 Гб рамы и тормозит.
|
|||
|---|---|---|---|
|
#18+
Вначале вашего проблемного запроса добавьте explain (analyze, costs, buffers, timing) пример: explain (analyze, costs, buffers, timing) ваш_запрос; Покажите результат запроса. Про EXPLAIN можно почитать цикл статей EXPLAINING THE UNEXPLAINABLE и перевод цикла Объясняя необъяснимое ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.05.2016, 19:10 |
|
||
|
Помогите с настройками пожалуйста. 64 Гб рамы и тормозит.
|
|||
|---|---|---|---|
|
#18+
shared_buffers = 1GB автор64 Гб рамы Не ясно, сколько занимают данные, но если сервер выделенный, то не соответствует 100%. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.05.2016, 20:06 |
|
||
|
Помогите с настройками пожалуйста. 64 Гб рамы и тормозит.
|
|||
|---|---|---|---|
|
#18+
Локшин Марк, shared_buffers = 1GB - случайно удалил, там было 16GB. Сейчас уже выставил 24GB. Нашли первое узкое место - lvm + reiserfs на 5,7Tb томе давали удивительно низкую производительность, не больше 12Мб/сек, а в среднем - 1-2Мб/сек. Сейчас убил LVM и форматнул физические винты на xfs каждый свои разделом. (На второй сыпятся данные кроме базы в большом объёме), в итоге скорость iotop показывает 100-200 Мб/сек. Я долго добивался от всех окружающих любых суждений о reiserfs 3, но ничего кроме "старьё" не услышал и не нашёл. Итог: reiserfs нельзя использовать потому что на большом диске он показал ужасающе низкую производительность на всех файлах, кроме больших (больше ~100 Мб). Да, и он не поддерживает trim на SSD, но это был не наш случай. Вот теперь время eхplain делать :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2016, 10:39 |
|
||
|
Помогите с настройками пожалуйста. 64 Гб рамы и тормозит.
|
|||
|---|---|---|---|
|
#18+
помощь нужна я можеет прйёл не туда ПО Secoros работает на основе постгреса ну вот пять камер категоричесски не хотят подключатся что делоть помогите!11 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2016, 12:19 |
|
||
|
Помогите с настройками пожалуйста. 64 Гб рамы и тормозит.
|
|||
|---|---|---|---|
|
#18+
и главные суки мельккнкли ну может там что есть про у постгреса про реиндедекс ну дайте инфу, умоляю ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2016, 12:24 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=39227962&tid=1997258]: |
0ms |
get settings: |
6ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
197ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
38ms |
get tp. blocked users: |
1ms |
| others: | 206ms |
| total: | 475ms |

| 0 / 0 |
