Вопрос наверно тупой.
PostgreSQL на Windows.
Сколько оперативки он может съесть?
Как увеличить объем потребляемой оперативки?
На Windows совсем плохо?

Насколько я понял PostgreSQL больше дает нагрузку на дисковую систему, чем на оперативку. То есть его быстродействие зависит в первую очередь от скорости чтения\записи на диск.
4 Гб оперативки на 10 пользователей, должно хватить...

В данный момент обновляю УПП под PostgreSQL. Оперативки 8 Гб, а дисковая система очень слабая и всё очень медленно и печально.

УПП, кстати, почти пустая.

2(1) ну вот человек и спрашивает как сделать так, чтобы он помещал куски базы в кэш - в оперативку, чтобы менял записи там, а не непосредственно на диске... что по идее должно давать более чем 100кратный прирост производительности. :)

(1) Вот в том то и проблема.
Но на диск дается нагрузка из-за того что не используется оперативка.
Должна быть настройка.
Смущает что под Windows только х86 вариант. И он у меня свои 3 Гб сожрал. :(
Можно ли как-то поднять объем используемой памяти?

(3) Опередил :)

2(4) на сайте 1С есть тестовая сборка нового Постгресса, под 64-бит

2(4) еще момент... это например МС СКЛ работает с ФС на низком уровне.. а Постгресс - ради уницированности - наверняка нет, стало быть через кэш... у тебя кэш в винде какой?

(6) Не нашел.
(7)Кэш по умолчанию.

fsync=off запрещает запись на диск после каждого изменения данных. Скорость за счет надежности... Это увеличит расход оперативки за счет уменьшения количества обращений к диску, потом начнется аъхтунг, когда вместо оперативки начнет использоваться файл подкачки.

(8) http://screencast.com/t/M1RzwMUHuu
по умолчанию и для разных версий винды это разные вещи

2(9) ну а если он не начнет использоваться вовсе? Если памяти 40 Гиг, а треклятая субд использует не более 3 Гиг из этого бассейна? И все что мы хотм - это использовать скажем 8 Гиг, чтобы в ОЗУ помещалось например половина базы?

(10) Дома посмотрю. На работе сайт закрыт.

У меня сейчас из 8 Гб свободно 5.5 Гб при этом файл подкачки вырос с 700 Мб в начале обновления до 3,36 Гб на сейчас. Надежность подразумевает запись на диск результатов трансакций. Сначало пишется ЛОГ-трансакции, потом после его успешной записи на диск, изменяется сама таблица СУБД на диске. Если нужна скорость в ущерб надежности - используйте файловую СУБД, которую 1С даёт по умолчанию :-)))

Как настроить PostgreSQL так чтобы он жрал оперативку, ответ - не знаю. Делайте больше оперативки и создавайте виртуальный жесткий диск и устанавливайте PostgteSQL на него :-)))

2(12) ну нет, это не серьезно... нормальные СУБД :) имеют возможность использовать СУБД, еще более нормальные позволяют указывать размер отдельных кэшей, процент грязности кэшей и т.д..
И кстати, пишется в лог на диск - это одно, а изменяются записи в таблице - и где эти таблицы мы хотим чтобы сейчас были - это другое.. человек пока про лог транзакций ничего не говорил, пусть и пишется на диск как сейчас и происходит... говорил что хочет чтобы таблицы менялись в памяти, а уж потом, по свободе, например, когда пользователи ни чего не меняют, когда очередь к диску свободна, уже экстернализировались бы таблицы на диск

"имеют возможность использовать ОЗУ"

(4) Никто вам не мешает ставить 32 битный Postgres на 64 битную ОС, тогда ему будут доступно столько памяти сколько увидит 64 битная ОС, 64 битность PostgreSQL, вряд ли даст прирост производительности, так как опять же производительность зависет в первую очередь от скорости дисковой системы.
(13) Насколько я знаю, PostgreSQL имеет такую возможность - настраивать величину кэшей, но только с детальной настройкой помочь ни чем не могу, кроме, разве что, послать по известному адресу :-))) http://citforum.ru/database/postgres/FAQ_russian.shtml

2(15)"32 битный Postgres на 64 битную ОС, тогда ему будут доступно столько памяти сколько увидит 64 битная ОС" - а вот и нет, а вот и враки... По крайней мере для Винды - хрен он что увидит

и потому человек и спрашивает про 64-битную версию Постгресса, чтобы она увидела более 3 Гиг РАМ, и могла бы заюзать под свой кэш больше РАМ, и ускорить операции записи в базу.

Серьезно? Не знал...

где-то тут была статья о том сколько какие приложения (сколькобитные и с какими ключами скомпиленные) могут заюзать в разных ОС (разной битности)

админ в отпуск только ушел, он как то настраивал, что у нас вроде как постгри ест больше оперативки, нежели винт
как - хз, не скажу
появится только через 2 недели
но - постгри на линухе

(20) Теперь знаем к кому приставать с вопросами :-)

(19) я этот вопрос изучу. Я как то даже не задумывался на эту тему...

2(22) http://gilev.blogspot.com/2010/06/limits-of-virtual-memory-in-windows.html

"Виртуальное адресное пространство для одного 32-разрядного процесса"

Под одним процессом следует понимать один postgres.exe в диспетчере задач?

да... а что, можно сделать так чтобы два процесса обслуживали одну базу данных?

Я не знаю этого. Но у меня сейчас в состоянии покоя висит 7 процессов. Я понимаю, что за изменения таблиц отвечает из них один процесс, один за вакуум, третий за лог... и каждому их них доступно по 3 гига. Значит и тому, что записывает изменения доступны только 3 гига, раз он 32 битный....

и все процессы называются одинаково? серьезно?
На как бы там ни было, интересует чтобы процесс который пишет непосредственно в базу данных - а их... ну... не могу представить чтобы их было несколько для одной базы данных, хотя это конечно ничего и не доказывает кроме отсутствия у меня фантазии... так вот чтобы он использовал-то памяти побольше...
Ну. :) меня бы на месте ТС интересовало.

Ну да, я так и думаю, что только один из них пишет в таблицы. Именно о нем речь и идёт. Всё верно, ему доступно только 3 гб памяти, что бы увеличить этот объем нужно поставить 64 битный Postgres, а что бы заставить использовать оперативную память, вместо того что бы постоянно писать низменения на жесткий, нужно разбираться с настройками. :-)

вооот... с волшебными крутилками, которые наверняка есть.... вот о них и грезит ТС.

Ну тут я ему ничем помочь не могу. Зато понял, что мне нужно ставить 9-ю 64-битную версию с сайта 1С, а потом я сюда приду с воплем - "почему не могу восстановить базу, из дампа сделанного из 32 битной версии?" :-) Такие вопли читал на форумах, пока пытался разобраться с настройками.

(20) Ждем админа :)

(1) "Насколько я понял PostgreSQL больше дает нагрузку на дисковую систему, чем на оперативку. То есть его быстродействие зависит в первую очередь от скорости чтения\записи на диск. "

Если PostgreSQL нагружает дисковую систему...
один из вариантов ускорения дисков это делать чередующими.

http://blogs.pcmag.ru/node/74

Бери 4 диска и сделай их чередующими.

Теоретический быстродействие диска должен быть увеличено 4 раза.

кстати, тут читал, что на 8.2 комфортнее базы создавать на пг. проверяли кто-нить?

(34) ничего отличающегося от создания баз на 81 не нашел

У нас все базы на постгри (пока). Насколько я понял там каждое подключение пользователя создает подключение к  базе, то есть если у нас около 60 пользователей в бухгалтерии, то около 50 подключений к базе (хорошо в проге pgadmin видно). Винты sas - зеркало, стоит на линуксе, 8гб оперативки. Но когда на этот же сервер поставили зарплату (еще 30 человек) то начались жуткие тормоза в обеих базах. Так что зарплату вернули обратно на старый сервак. А по настройкам памяти лучше всего у Гилева

(0) на win плохе. Не заточен.

(36) ээ.. а как же это, зарплатчиков 30 человек? ;)

(38) - да у нас там начальство нафантазировало - сделали формочку чтобы в цехах всякие-разные мастера-экономисты табель заполняли каждый день... типа кто прогулял, кто опоздал...

(32) Спасибо - изучу...

(33) RAID-0 штука не надежная, лучше RAID-10.
То, что быстродействие диска увеличиться, не совсем так.
Время поиска записи на диске не уменьшается, время случайной записи на диск не уменьшается, чем больше в работе доля случайных записей, тем более в меньшую сторону будет отличаться прирост производительности от теоретического...

http://rutracker.org/forum/viewtopic.php?t=3120721

Не, он прав - чем больше шпинделей, тем быстрее... в среднем. Но это а) дороже... б) не имеет настолько разительного эффекта как правильно настроенный кэш.

"It’s All About the Spindles, Baby
If the SAN creates a performance bottleneck, then one discussion you will want to have
is about the spindles. A spindle is a SAN administrator’s slang for an individual drive that
is combined together with other drives to make arrays. For example, you could have ten
disks in an array, build five logical volumes on those ten disks, and each volume would
have ten spindles. But if two or more of those volumes are put under stress, then all ten
spindles are under stress. In an ideal configuration, your SAN would have as many
spindles as possible and a minimal chance for resource contention.
Want to have some fun? Go and ask your SAN administrator this question: “If my
current LUNs were converted into physical disks, how many spindles would I have
allocated?” If the number is low, then you may have cause for concern. Again, that is
why I stress the importance of benchmarking. "

(42) Я с этим не спорю, я говорю, что быстродействие не прямо пропорционально количеству шпинделей. А правильно настроенный кэш, это конечно важно.