Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Помогите PostgreSQL настроить
|
|||
|---|---|---|---|
|
#18+
Как примерно postgresql.conf должен выглядеть для этого: Postgres v7.4.6 Память 1Гб На винте места 15Гб Всего 20 таблиц. Самая большая пока 10млн записей. 10 таблиц 100тыс-1млн. Остальные совсем маленькие. База используется только для хранения данных. Одновременное чисто коннектов 5-10 максимум. Каждую ночь - добавление по 1000-10000 записей. А вообще проблема в том, что Insert в таблицу с 10млн очень медленно работает, иногда 1 запись могла до минуты вставляться. С Delete таже проблема. Раньше был 7.3, после небольшой настройки удалось немного ускорить, но в конце концов перешли всё-таки на 7.4, и памяти добавили. Безрезультатно. Знаю что дело в основном в Foreign Key, но их отключать никак нельзя. ЗЫ: http://detail.phpclub.net/store/html/postgresql/node2.html Наверное многие это читали. Что означает "1-4 ГБ доступной памяти", "можете взять 2-4% доступной памяти"? Это про оперативную память, или про что? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 10:45 |
|
||
|
Помогите PostgreSQL настроить
|
|||
|---|---|---|---|
|
#18+
Конечно оперативная память. Поиши здесь по форуму, SadSpirit выкладывал FAQ по настройке, на удобном русском. Наверно ещё стоит разобратся с "VACUUM ANALYZE" и "VACUUM". http://www.postgresql.org/docs/7.4/static/maintenance.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 11:05 |
|
||
|
Помогите PostgreSQL настроить
|
|||
|---|---|---|---|
|
#18+
NiemiНаверно ещё стоит разобратся с "VACUUM ANALYZE" и "VACUUM". Какое влияние на ситуацию может оказать VACUUM, если данные согласно описанию не удаляются вообще? [это не риторический вопрос, а просто вопрос ;)] ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 11:38 |
|
||
|
Помогите PostgreSQL настроить
|
|||
|---|---|---|---|
|
#18+
Код: plaintext Странно всё это. ТАКИЕ тормоза!!! С чего? Покажи файл postgres.conf. Можно не весь. Интересуют части Shared Memory Size, Non-shared Memory Sizes, Write-ahead log. Ещё момент. Вставка - это обычный INSERT INTO ... VALUES(...)? Или вместо VALUES SELECT стоит? Может просто запросы у тебя не оптимальны? Автосбор статистики стоит? Некоторые это дело любят отключать. Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 13:26 |
|
||
|
Помогите PostgreSQL настроить
|
|||
|---|---|---|---|
|
#18+
очень хорошая статья и по русски Читал, конечно. Из-за того, что она по-русски, ума не прибавилось. Исключительно теоретические знания. А что на что влияет, и в каких ситуациях - только на собственном опыте, или у других спросить. Вот и спрашиваю. Как для описанной конфигурации всё нормально настроить? Или, что может на производительность повлиять очень сильно? Эксперементировать можно долго. У более опытных людей, думаю, опыта в этом должно быть гораздо больше. Вставка - это обычный INSERT INTO ... VALUES(...)? Да. Покажи файл postgres.conf Все настройки по умолчанию. Изменялось многое, но только в целях эксперимета. После того как обнаруживалось, что результата это почти не приносит, ставилось обратно. Вероятно, надо изменять комплексно, и с умом. Вопрос - что? Всё, что изменено на данный момент. Остальное по умолчанию. 7.3. shared_buffers = 2048 В свежеустановленном 7.4.6: shared_buffers = 8192 Что у тебя за схема тогда?!?!?! Хоть и риторический вопрос, но всё-же. Вот, пожалуйста. Сам удивляюсь. Не моя, я-бы до такого не додумался. Жуткая вещь, приблизительно выглядит так: site: (20 записей) _____ поля: site_id users: (200 записей) __ поля: users_id, site_id. __ key: _____ site_id= site .site_id orders: (500000 записей) __ поля: orders_id, site_id, cash_user, driver_user, fill_user __ key: _____ site_id= site .site_id _____ (site_id+cash_user)= users .(site_id+users_id) _____ (site_id+driver_user)= users .(site_id+users_id) _____ (site_id+fill_user)= users .(site_id+users_id) orders_line: (1млн записей) __ поля: orders_line_id, site_id, orders_id, parent_id, stock_id, good_id __ key: _____ site_id= site .site_id _____ good_id= good .good_id _____ (site_id+orders_id)= orders .(site_id+orders_id) _____ (site_id+parent_id)= orders_line .(site_id+parent_id) _____ (site_id+stock_id)= stock .(site_id+stock_id) orders_line_baker: (500000 записей) __ поля: orders_line_baker_id, site_id, orders_line_id __ key: _____ site_id= site .site_id _____(site_id+orders_line_id)= orders_line .(site_id+orders_line_id) stock: (1 млн записей - На этой очень сильно тормозит при Delete. Окончания за 2ое суток не дождался.) __ поля: stock_id, site_id, user_id, stock_div_id __ key: _____site_id= site .site_id _____stock_div_id= stock_div .stock_div_id _____(site_id+users_id)= users .(site_id+users_id) stock_line: (10 млн записей - На этой тормозит при Insert) __ поля: stock_line_id, site_id, stock_id, item_id __ key: _____site_id= site .site_id _____item_id= item .item_id _____(site_id+stock_id)= stock .(site_id+stock_id) Ну, и ещё несколько штук, поменьше. item, good, stock_div, stock_size, customer, address, time_sheet, remains, remains_line . На всех, соответственно тоже ключи (site_id + ..._id), или просто (site_id) Если всё это отключить, всё работает быстро, но из-за постоянных обрывов связи, образуется много всего ненужного, поэтому совсем отключать нельзя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 17:32 |
|
||
|
Помогите PostgreSQL настроить
|
|||
|---|---|---|---|
|
#18+
Вот моё, сервер 7.3 Памяти тоже гиг, если на машине кроме Постгеса нет ничего, то можно увеличивать буфера # # Shared Memory Size # shared_buffers = 131072 # min max_connections*2 or 16, 8KB each max_fsm_relations = 1000 # min 10, fsm is free space map, ~40 bytes max_fsm_pages = 32000 # min 1000, fsm is free space map, ~6 bytes #max_locks_per_transaction = 64 # min 10 wal_buffers = 128 # min 4, typically 8KB each # # Non-shared Memory Sizes # sort_mem = 20480 # min 64, size in KB vacuum_mem = 20480 # min 1024, size in KB и ещё эти параметры effective_cache_size = 32000 # typically 8KB each geqo = true stats_start_collector = true Теперь о плохом. я не понял этих записей (site_id+cash_user)=users.(site_id+users_id) что это означает? Если не трудно команды создания основных таблиц приведи, можно обрезав поля по которым связей нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 17:53 |
|
||
|
Помогите PostgreSQL настроить
|
|||
|---|---|---|---|
|
#18+
Спасибо, попробую. (site_id+cash_user)=users.(site_id+users_id) означает вот это Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 18:22 |
|
||
|
Помогите PostgreSQL настроить
|
|||
|---|---|---|---|
|
#18+
интересно вяжетесь: П-кей у вас (юзер, сайт) - тут создаются индексы а ф-кеи (сайт,юзер) (надежда на автоматическое создание индексов (сайт,юзер) ф-кеями?) - для ф-кеев (постгресом) индексы, кажется, не создаются. надо самомму. есть ли определения индексов для ф-кеев? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 18:54 |
|
||
|
Помогите PostgreSQL настроить
|
|||
|---|---|---|---|
|
#18+
to 4321 Мне почему-то подумалось, что Постгрес заюзает индекс (сайт,юзер) при внешнем ключе (юзер,сайт). Хотя может быть, может быть. А удаление из stock? stock: (1 млн записей - На этой очень сильно тормозит при Delete. Окончания за 2ое суток не дождался.) __ поля: stock_id, site_id, user_id, stock_div_id __ key: _____site_id=site.site_id _____stock_div_id=stock_div.stock_div_id _____(site_id+users_id)=users.(site_id+users_id) Товарищ vadim_123, а у вас случайно винт не посыпался? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 19:43 |
|
||
|
Помогите PostgreSQL настроить
|
|||
|---|---|---|---|
|
#18+
И ещё. Те настройки Постгреса, которые я привёл, они больше на выборки повлияют. То есть данные с диска в память закешируется, больше будут буфера при сортировке -> свопить не будет, результаты запросов и планы выполнения тоже в памяти будут дольше оставаться. Это всё повышает производительность при выборках, но не при вставках и удалениях. ((( Посему, окромя физической проверки винта, можно порекомендовать VACUUM ANALYZE и периодически перестраивать индексы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2004, 19:50 |
|
||
|
Помогите PostgreSQL настроить
|
|||
|---|---|---|---|
|
#18+
mwolfto 4321 Мне почему-то подумалось, что Постгрес заюзает индекс (сайт,юзер) при внешнем ключе (юзер,сайт). Хотя может быть, может быть. Вероятно (в силу здравого), но не обязательно. Главное - нет индексов для самих ф-кеев. А это более критично для джойнов (на той стороне записёв обычно поболее в разы-:-разы порядков) , а сталбыть и для проверки целостности (при удалениях и первичного ключа главной). И все таки думается желательно иметь для джойнов индексы (на обеих сторонах) одинаково упорядоченные (не факт, что вязка по черт те как упорядоченным индексам столь же прозрачна, хотя и внутри "атомарной операции выборки" - подставить в селект данные индексных полей из одной таблицы + запросить записи второй по полному набору полей ее индекса - вроде бы все и моноявственно). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2004, 15:16 |
|
||
|
Помогите PostgreSQL настроить
|
|||
|---|---|---|---|
|
#18+
Оффтопик: объясните мне пожалуйста сакральный смысл таблицы, состоящей всего из одной колонки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2004, 15:27 |
|
||
|
Помогите PostgreSQL настроить
|
|||
|---|---|---|---|
|
#18+
Кувалдин РоманОффтопик: объясните мне пожалуйста сакральный смысл таблицы, состоящей всего из одной колонки?У нас такая есть. Нужна именно для хранения в ней первичного ключа. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 09:32 |
|
||
|
Помогите PostgreSQL настроить
|
|||
|---|---|---|---|
|
#18+
1. Винт рабочий 2. Все индексы пересоздал в соответствии с порядком, в котором перечисляются поля при создании ключей. В смысле - index=(site_id, user_id) key=(site_id, user_id) 3. Также создал индексы в таблицах, в которых создаются ключи. 4. На всякий случай, reindex, vacuum analyze Результат - ноль внимания со стороны постгреса. Как будто ничего и не делал. Кувалдин Роман Оффтопик: объясните мне пожалуйста сакральный смысл таблицы, состоящей всего из одной колонки?] Невнимательно смотрели. У меня нет таких таблиц. Хотя вариантов, при которых это может понадобится существует очень много. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 10:26 |
|
||
|
Помогите PostgreSQL настроить
|
|||
|---|---|---|---|
|
#18+
INSERT может сильно тормозить только если при его выполнении совершаются какие-то непонятные телодвижения. Допустим, с внешними ключами всё нормально, тогда сразу два доп. вопроса: 1) Построены ли по таблице какие-либо хитрые индексы (в смысле не типа btree)? 2) Висят ли на таблице триггеры кроме триггеров внешних ключей? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 11:18 |
|
||
|
Помогите PostgreSQL настроить
|
|||
|---|---|---|---|
|
#18+
Триггеров нет Все индексы btree ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 11:30 |
|
||
|
Помогите PostgreSQL настроить
|
|||
|---|---|---|---|
|
#18+
Кидайте pg_dump -s и текст запроса, который выполняется медленнее, чем хочется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 11:46 |
|
||
|
Помогите PostgreSQL настроить
|
|||
|---|---|---|---|
|
#18+
LeXa NalBatтекст запроса, который выполняется медленнее, чем хочется. Мда..., где-ж вы были раньше? Есть программа, которая переносит данные из одной базы в другую. На скорость её работы я в основном и ориентировался. Очень внимательно взглянул на её текст. Мне казалось, что такую прогу как-то не так написать очень сложно. Её автор, очевидно думал не так. Текст запроса привести не могу, потому что не вполне понимаю, как он вообще создаётся. А простой Insert намного быстрее заработал после пересоздания индексов. Просто забыл проверить отдельно от этой чудо-программы. Буду разбираться с автором, всем спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2004, 13:05 |
|
||
|
Помогите PostgreSQL настроить
|
|||
|---|---|---|---|
|
#18+
vadim_123Невнимательно смотрели. У меня нет таких таблиц. Хотя вариантов, при которых это может понадобится существует очень много. site: (20 записей) _____ поля: site_id Вот и объясните мне, зачем в базе, основанной на связи "ключ-значение" хранить ключи отдельно от значений. Первичные ключи хранить отдельно от значений, связанных с ними, ИМХО бессмысленно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2004, 15:10 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=32844428&tid=2007517]: |
0ms |
get settings: |
9ms |
get forum list: |
22ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
52ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
65ms |
get tp. blocked users: |
1ms |
| others: | 238ms |
| total: | 406ms |

| 0 / 0 |
