Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / PostgreSQL |
![]() ![]() |
ignitor Member Откуда: Уфа Сообщений: 134 |
Железо - Intel Xeon 5110 1.6GHz памяти 2GB винты SATA 3 шт без RAID на одном операционка на другом база на третьем копии. ОС Windows server 2003 Std SP2 До изменений из 3 баз сливалась в ко мне за 30минут, теперь 3 часа. Помогите советом! Спасибо Переменные через show all;
|
17 авг 07, 13:07 [4539422] Ответить | Цитировать Сообщить модератору |
Andrey Daeron Member Откуда: Киев Сообщений: 1027 |
Может кто еще чего поумнее посоветует... Я бы для начала поднял бы память: work_mem 8MB maintenance_work_mem 64MBдо каких-то более исмпатичных значений. Может поможет. |
17 авг 07, 14:04 [4539929] Ответить | Цитировать Сообщить модератору |
ignitor Member Откуда: Уфа Сообщений: 134 |
Судя по доке, ета память отвечает вовсе не за INSERT. Добавлю так же, что инсерты я делаю в базы без индексов, т.е. DROP , куча INSERT, затем CREATE INDEX.
|
||||
17 авг 07, 14:27 [4540110] Ответить | Цитировать Сообщить модератору |
zsm Member Откуда: Санкт-Петербург Сообщений: 71 |
А я бы попробовал отключить fsync. Хорошо помогает ;-) |
17 авг 07, 15:31 [4540779] Ответить | Цитировать Сообщить модератору |
ignitor Member Откуда: Уфа Сообщений: 134 |
Ага, потом базу с бэкапа поднимать ... Нет fsync и раньше был включен и меня все устраивало. Я увеличил
Но vacuum выполняется безумно долго. Что за беда? |
||
17 авг 07, 15:39 [4540852] Ответить | Цитировать Сообщить модератору |
ignitor Member Откуда: Уфа Сообщений: 134 |
Уточню - VACUUM FULL ANALYZE Просто VACUUM ANALYZE выполняется: INFO: vacuuming "public.accanl" INFO: scanned index "idx1" to remove 20621 row versions DETAIL: CPU 0.00s/0.01u sec elapsed 1.46 sec. INFO: scanned index "idx_1" to remove 20621 row versions DETAIL: CPU 0.00s/0.01u sec elapsed 1.56 sec. INFO: scanned index "idx2" to remove 20621 row versions DETAIL: CPU 0.00s/0.04u sec elapsed 3.98 sec. INFO: scanned index "idx20" to remove 20621 row versions DETAIL: CPU 0.00s/0.00u sec elapsed 1.96 sec. INFO: scanned index "idx33" to remove 20621 row versions DETAIL: CPU 0.00s/0.01u sec elapsed 2.71 sec. INFO: scanned index "idx30" to remove 20621 row versions DETAIL: CPU 0.00s/0.00u sec elapsed 2.01 sec. INFO: scanned index "idx31" to remove 20621 row versions DETAIL: CPU 0.03s/0.00u sec elapsed 5.89 sec. INFO: scanned index "idx32" to remove 20621 row versions DETAIL: CPU 0.00s/0.01u sec elapsed 1.92 sec. INFO: "accanl": removed 20621 row versions in 5633 pages DETAIL: CPU 0.09s/0.10u sec elapsed 55.53 sec. INFO: index "idx1" now contains 59377 row versions in 293 pages DETAIL: 14243 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: index "idx_1" now contains 59377 row versions in 243 pages DETAIL: 14243 index row versions were removed. 6 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: index "idx2" now contains 59377 row versions in 561 pages DETAIL: 14243 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: index "idx20" now contains 59377 row versions in 249 pages DETAIL: 14243 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: index "idx33" now contains 59377 row versions in 234 pages DETAIL: 14243 index row versions were removed. 30 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: index "idx30" now contains 59377 row versions in 226 pages DETAIL: 14243 index row versions were removed. 34 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: index "idx31" now contains 59377 row versions in 323 pages DETAIL: 14243 index row versions were removed. 42 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: index "idx32" now contains 59377 row versions in 221 pages DETAIL: 14243 index row versions were removed. 49 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: "accanl": found 20621 removable, 59377 nonremovable row versions in 11144 pages DETAIL: 0 dead row versions cannot be removed yet. There were 255 unused item pointers. 5489 pages contain useful free space. 0 pages are entirely empty. CPU 0.12s/0.21u sec elapsed 93.68 sec. INFO: vacuuming "pg_toast.pg_toast_226403" INFO: index "pg_toast_226403_index" now contains 0 row versions in 1 pages DETAIL: 0 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: "pg_toast_226403": found 0 removable, 0 nonremovable row versions in 0 pages DETAIL: 0 dead row versions cannot be removed yet. There were 0 unused item pointers. 0 pages contain useful free space. 0 pages are entirely empty. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: analyzing "public.accanl" INFO: "accanl": scanned 11144 of 11144 pages, containing 59377 live rows and 0 dead rows; 59377 rows in sample, 59377 estimated total rows Total query runtime: 112813 ms. Хотя раньше с FULL хватало 20 секунд |
17 авг 07, 15:55 [4541034] Ответить | Цитировать Сообщить модератору |
zsm Member Откуда: Санкт-Петербург Сообщений: 71 |
А если восстановить все парамерты по-умолчанию и найти все отличия, которые были вами внесены? Хотя предполагаю, что вы это уже сделали... И еще одна мысль. У нас были проблемы с производительностью дисковой подсистемы (SATA on RAID) сразу после уставновки Windows server 2003 Std SP2. С SP1 все работало замечательно. Есть преположение, что это как-то связано с драйверами. Эту проблему пока так и не решили (руки никак не дойдут). Возможно, есть смысл измерить, все ли здесь в порядке... |
17 авг 07, 16:01 [4541091] Ответить | Цитировать Сообщить модератору |
Thamerlan Member Откуда: Рига Сообщений: 203 |
checkpoint_segments 3 имхо, маловато будет. Поставьте 16 хотя бы |
17 авг 07, 16:13 [4541176] Ответить | Цитировать Сообщить модератору |
ignitor Member Откуда: Уфа Сообщений: 134 |
Поставил 64MB и 300МВ соответственно
Поставил 16 Стал тестировать один процесс - стабильно давал 120 секунд выполнения. Затем стал менять настройки, пробуя уменьшать\увеличивать значения В итоге получилось стабильно (среднее из 7 значений от 83 до 112) 92 секунды выполнения при следующих параметрах: set shared_buffers =512MB;-- было 256MB set work_mem =100MB;-- было 64MB set wal_buffers =192kB;-- было 1MB set maintenance_work_mem =500MB;-- было 200MB --ну и для кучи set effective_cache_size =800MB;-- было 400MB особенно отличился wal_buffers В процессе используется DROP;CREATE TABLE;COPY FROM; UPDATE; CREATE INDEX;VACUUM FULL ANALYZE; Однако на скорость INSERT это не повлияло. Теперь я стал припоминать, что давно не обращал на этот процесс внимания и SP2 на 2003 сервер поставил недавно. Так что я все больше склоняюсь к мнению, что причина в нем. Попробую проверить на резервном сервере. |
||||
17 авг 07, 19:47 [4542392] Ответить | Цитировать Сообщить модератору |
ignitor Member Откуда: Уфа Сообщений: 134 |
Нашел гада! Подложил я пустой postgresql.conf (ну не совсем, чтобы сконнектится можно было) и, о чудо! Все вернулось на место! Стал я по одному присваивать параметры, что менял и смотреть что будет. Сделал процесс который вставляет 10000 записей и попробовал на чистом конфиге. Вышло 18 секунд, потом стал "улучшать" и дошел до 16 секунд. Но! Как только я высатавил
тут же получил 286 секунд (почти 17 раз). Для интереса попробовал все остальные методы. fdatasync,open_sync не запустился сервис fsync_writethrough 283 секунды. Итак выбор редакции:
что и было в настройках по умолчанию. Закончу тесты на остальные параметры, которые я потрогал - опубликую "золотой" postgresql.conf |
18 авг 07, 18:24 [4543599] Ответить | Цитировать Сообщить модератору |
Shweik Member Откуда: Сообщений: 705 |
Советую ознакомиться. http://www.opennet.ru/docs/RUS/postgresql_tune/ Там кстати кой-чего сказано и про параметр который ты "соптимизировал" ;) |
18 авг 07, 19:41 [4543669] Ответить | Цитировать Сообщить модератору |
ignitor Member Откуда: Уфа Сообщений: 134 |
А как же моя вчерашняя задача. Первые опыты показали, что с моими успешными для инсерта настройками задача показывает в среднем 109 сек. В чем же разница? И тут я вспомнил, про:
И действительно checkpoint_segments=16 привело к тому, что вчерашний рекорд был побит и среднее время выполнения задачи свелось к 66 секундам. Непонятно только одно, при значении 3 разброс по абсолютным значениям был от 79 до 115, а при 16 составил от 51 до 101 секунды. Впрочем я доволен и публикую последний вариант postgresql.conf
|
||
18 авг 07, 19:47 [4543681] Ответить | Цитировать Сообщить модератору |
ignitor Member Откуда: Уфа Сообщений: 134 |
Ну читать-то я ее читал, а сунулся оптимизировать после того как посмотрел здешний postgresql.conf Почесал я в затылке и подумал: "У них 16GB у меня 2GB". Короче, что касалось памяти поделил на 8. В общем - балда. Зато наука. |
||
18 авг 07, 20:01 [4543697] Ответить | Цитировать Сообщить модератору |
Все форумы / PostgreSQL | ![]() |