|
Действия ...
|
19.02.2014, 05:47:44
|
|||
|---|---|---|---|
|
|||
Тормоза на Win2008 R2 x64 |
|||
|
|
|
25.02.2014, 22:45:02
|
|||
|---|---|---|---|
|
|||
Тормоза на Win2008 R2 x64 |
|||
|
|
|
27.02.2014, 04:43:36
|
|||
|---|---|---|---|
|
|||
Тормоза на Win2008 R2 x64 |
|||
|
|
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
12.02.2014, 17:07:45
|
|||
|---|---|---|---|
|
|||
Тормоза на Win2008 R2 x64 |
|||
|
#18+
У одного клиента в отличии от большинства остальных стоит не CentOS, а Win2008 R2 x64. Причем именно у него достаточно простая логика и относительно не сложные запросы. Так вот раз в месяц три процесса начинают серьезно тормозить сервер, из-за жесткого насилования веника на чтение. При этом как правило повисают надолго именно на командах типа DELETE FROM t_число где t_число временная таблица. В логах ничего особенного нет. Конфигурация достаточно стандартная: Версия: PostgreSQL 9.3.1, compiled by Visual C++ build 1600, 64-bit Памяти всего 8Gb Из дефолт настроек изменены только: shared_buffers = 2Gb temp_buffers = 256Mb work_mem = 32Mb При этом свободной оперативки минимум 2-3 Gb. Все три процесса насилуют следующие файлы: C:\Program Files\PostgreSQL\9.3\data\base\16396\t19_347016 (у каждого свои циферки) С чем все это может быть связано, в смысле как диагностировать и лечить такие явления природы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.02.2014, 13:47:11
|
|||
|---|---|---|---|
Тормоза на Win2008 R2 x64 |
|||
|
#18+
Проверено (на 8.4) что чем больше shared_buffers под виндой , тем хуже. Оптимум в районе где-то 256MB-512MB ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.02.2014, 13:48:58
|
|||
|---|---|---|---|
Тормоза на Win2008 R2 x64 |
|||
|
#18+
Возможно, это как-то связано с переносом shmget под винду, не знаю уж... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
18.02.2014, 11:17:49
|
|||
|---|---|---|---|
|
|||
Тормоза на Win2008 R2 x64 |
|||
|
#18+
HawkmoonПроверено (на 8.4) что чем больше shared_buffers под виндой , тем хуже. Оптимум в районе где-то 256MB-512MB Что интересно через пару часов все приходит в норму. Но вообще да, похоже есть какой-то косяк с shared_buffers под виндой. Жаль пока не так много где проверить, везде CentOS в основном ставим :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
18.02.2014, 15:37:47
|
|||
|---|---|---|---|
|
|||
Тормоза на Win2008 R2 x64 |
|||
|
#18+
Временные таблицы, да? Надо бы изучить вопрос как в 9.3 обстоят дела с взаимодействием автовакуума с ними. Раньше он их просто игнорировал, возможно в 9.3 это уже не так и массовые удаления вызывают потребность в резком пересчете статистики итп? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.02.2014, 05:47:44
|
|||
|---|---|---|---|
|
|||
Тормоза на Win2008 R2 x64 |
|||
|
#18+
НезалогинившийсяВременные таблицы, да? Надо бы изучить вопрос как в 9.3 обстоят дела с взаимодействием автовакуума с ними. Раньше он их просто игнорировал, возможно в 9.3 это уже не так и массовые удаления вызывают потребность в резком пересчете статистики итп? в 9.3 временные таблицы так и игнорируются автовакумом... и будут игнорироваться и дальше (если вдруг временные таблицы с 0 не перепишут).... там архитектурные причины почему автовакум с ними работать не может ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.02.2014, 15:35:56
|
|||
|---|---|---|---|
|
|||
Тормоза на Win2008 R2 x64 |
|||
|
#18+
Разобрались. Проблема похоже во временных таблицах, которые pool'ся и при переиспользовании делается DELETE FROM, заполнение данных и ANALYZE, но не делается VACUUM. В результате через некоторое время они дорастают до огромных размеров на диске (правда непонятно почему через некоторое время работа восстанавливалась, видимо все же по какому то событию VACUUM все же trigger'ся). Что касается винды это похоже просто совпадение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.02.2014, 16:53:21
|
|||
|---|---|---|---|
|
|||
Тормоза на Win2008 R2 x64 |
|||
|
#18+
Nitro_Junkie, У вас безусловный DELETE FROM времнных таблиц? Тогда по всем параметрам дешевле их TRUNCATE. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.02.2014, 22:45:02
|
|||
|---|---|---|---|
|
|||
Тормоза на Win2008 R2 x64 |
|||
|
#18+
Nitro_Junkie(правда непонятно почему через некоторое время работа восстанавливалась, видимо все же по какому то событию VACUUM все же trigger'ся). ни по какому.... просто в какой то момент коннект к базе отваливается.... и вместе с коннектом умирают его временные таблицы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.02.2014, 23:59:33
|
|||
|---|---|---|---|
|
|||
Тормоза на Win2008 R2 x64 |
|||
|
#18+
Жоао!Nitro_Junkie, У вас безусловный DELETE FROM времнных таблиц? Тогда по всем параметрам дешевле их TRUNCATE. TRUNCATE нельзя использовать в READ ONLY режиме. А его выключать ради временных таблиц не хочется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.02.2014, 00:02:33
|
|||
|---|---|---|---|
|
|||
Тормоза на Win2008 R2 x64 |
|||
|
#18+
Maxim Boguk, Там то, как раз не должно быть момента отваливания connection'а, так что дело в чем то другом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.02.2014, 04:43:36
|
|||
|---|---|---|---|
|
|||
Тормоза на Win2008 R2 x64 |
|||
|
#18+
Nitro_JunkieMaxim Boguk, Там то, как раз не должно быть момента отваливания connection'а, так что дело в чем то другом. Что значить не должно быть? даже при использованиии пулера коннекто у коннекта к базе есть TTL свой (максимальный возраст коннекта к базе после чего он принудительно закрывается) что для pgbouncer что для pgpool что для любых java connnectoon pooler (Типа c3p0) что для любых известных мне велосипедов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.02.2014, 17:04:22
|
|||
|---|---|---|---|
|
|||
Тормоза на Win2008 R2 x64 |
|||
|
#18+
Maxim Boguk, Ну в данном случае, речь идет о собственном пулинге, и если в спецификации jdbc, в стандартном драйвере, и у самой СУБД TTL нет по умолчанию, то дело все же не в этом :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.02.2014, 00:59:12
|
|||
|---|---|---|---|
|
|||
Тормоза на Win2008 R2 x64 |
|||
|
#18+
Nitro_JunkieMaxim Boguk, Ну в данном случае, речь идет о собственном пулинге, и если в спецификации jdbc, в стандартном драйвере, и у самой СУБД TTL нет по умолчанию, то дело все же не в этом :) ttl есть всегда... в самом плохом случае ttl наступает когда процессы базы начинает операционка отстреливать по OOM вечноживые коннекты к базе это очень плохо... 1-2-12 часов это разумно... больше нет... и еще раз скажу что место во временных таблицах можно почистить только через: 1)disconnect процесса базы 2)truncate Этих таблиц 3)drop эти таблиц... autovacuum с ними никогда не работал и работать не будет/может так как они существуют только в приватной памяти конкретного процесса базы и к их данным никто кроме этого процесса базы добраться не может. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=53&tablet=1&tid=1998815]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
200ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 228ms |
| total: | 510ms |
| 0 / 0 |
