Re: DBMail
В сообщении от Понедельник 16 июля 2007 14:59 proforg написал(a): > > > порядка 10-20 активных соединений, > > > > Какой пул - в смысле, PgPool или ...? > > никакого :) А в чём смысл его использования ? > Только префорк ? Или он ещё и поможет снизить количесво одноверменно > запущщеных процессов (сейчас 200-250) Ага, поможет. Создание и закрытие соединения с базой - процесс не быстрый. В то время как при наличии пула база спокойно будет обслуживать порядка тысячи одновременных запросов независимо от числа пользователей (без пула порядка сотни пользователей, а запросов еще меньше). Одно подключение пула "тянет" около 4-5 клиентов (зависит от того, насколько интенсивно они запросы шлют). Если одновременно работает не более 50-ти пользователей, 10 соединений пула должно хватить. Выигрыш производительности просто огромный (а если еще и софт заточить на работу с пулом, вообще сказка).
Re: DBMail
On 7/16/07, Pechnikov Alexey <[EMAIL PROTECTED]> wrote: > порядка 10-20 активных соединений, Какой пул - в смысле, PgPool или ...? никакого :) А в чём смысл его использования ? Только префорк ? Или он ещё и поможет снизить количесво одноверменно запущщеных процессов (сейчас 200-250) > пример плана выполнения запросов: Такое впечатление, что тело письма лежит в одной таблице с заголовками. Если так, то кроме огорчений, ждать нечего. Нет. Таблицы конечно разные. > postgresql конечно 8.2 а не 8.3 :) У меня 8.1, со следующим релизом дебиана перейду сразу на 8.3. > shared_buffers = 512MB Такой размер буферов требует гигов 8 или 16 оперативки. Поставьте 64 метра буфер. > work_mem = 256MB Аналогично. 256 метров КАЖДОМУ пользователю на его запрос, если одновременно 20 пользователей, нужно 5 гиг ОЗУ. А у вас сколько?.. Поправил :) Это я уже последние эксперименты увеличивал. Но вообще - свопа почти нет и при таких настройках. > я не думаю что тут проблема в структуре / настройках бд - скорее в > запросах :) Как всегда, проблемы не ходят по одиночке. Конечно, операция ILIKE на огромной таблице будет нереально медленно выполняться, а вот если заголовки писем сделать отдельной табличкой, будет совсем другое дело. Но и настройки надо поправить, при текущих постгрес будет думать, что на машине не меньше 8 Гиг ОЗУ и постоянно попадать в своп (использует знания о количестве ОЗУ на машине, прикидывая возможности кэширования файлов ОСью и не пытаясь дублировать эту работу). Заголовки - в отдельной. Но и количество записей там соотв в разы больше чем в таблице сообщений - ~30M. Так что джойны получаются совсем небыстрые. Не говоря уже о ILIKE. В общем-то, все довольно просто, хотя пока я допер до того, как надо делать, раза 3 или 4 целиком архитектуру системы переписывал (каждая итерация занимала примерно полгода времени у 2-х разработчиков). Сейчас использую связку Pound+AOLServer+Tcl+PostgreSQL+Pltcl. Жизнь прекрасна :-) вот видимо и придётся слегка переписывать dbmail :) и спасибо за советы -- Alexej Bestchiokov EMail/JID: [EMAIL PROTECTED] phone: +7 495 7853149
Re: DBMail
> порядка 10-20 активных соединений, Какой пул - в смысле, PgPool или ...? > пример плана выполнения запросов: Такое впечатление, что тело письма лежит в одной таблице с заголовками. Если так, то кроме огорчений, ждать нечего. > postgresql конечно 8.2 а не 8.3 :) У меня 8.1, со следующим релизом дебиана перейду сразу на 8.3. > shared_buffers = 512MB Такой размер буферов требует гигов 8 или 16 оперативки. Поставьте 64 метра буфер. > work_mem = 256MB Аналогично. 256 метров КАЖДОМУ пользователю на его запрос, если одновременно 20 пользователей, нужно 5 гиг ОЗУ. А у вас сколько?.. > я не думаю что тут проблема в структуре / настройках бд - скорее в > запросах :) Как всегда, проблемы не ходят по одиночке. Конечно, операция ILIKE на огромной таблице будет нереально медленно выполняться, а вот если заголовки писем сделать отдельной табличкой, будет совсем другое дело. Но и настройки надо поправить, при текущих постгрес будет думать, что на машине не меньше 8 Гиг ОЗУ и постоянно попадать в своп (использует знания о количестве ОЗУ на машине, прикидывая возможности кэширования файлов ОСью и не пытаясь дублировать эту работу). > > На таком железе терабайтную базу гонять можно. > > Как обычно - смотря какие запросы :) Запросы - какие надо. Главное, правильно спроектировать структуру. > Впрочем меня всегда интересовал вопрос как они вообще живут эти > террабайтный базы в реальной жизни. :-D По своему опыту пока могу сказать только о базе в несколько десятков Гиг на целероне 2,4 ГГц и 256 ОЗУ при 10-20 одновременных пользователях. Два года назад поставили "временно" на первый попавшийся комп, так там и живет, ибо справляется. Притом, что аналитика выдается в реальном времени и довольно сложная (система мерчендайзинга на макрорегион). Как и что устроено, рассказываю вот здесь: http://postgrestips.blogspot.com/2007/06/blog-post.html В общем-то, все довольно просто, хотя пока я допер до того, как надо делать, раза 3 или 4 целиком архитектуру системы переписывал (каждая итерация занимала примерно полгода времени у 2-х разработчиков). Сейчас использую связку Pound+AOLServer+Tcl+PostgreSQL+Pltcl. Жизнь прекрасна :-)
Re: DBMail
On 16.07.2007, at 12:17, Pechnikov Alexey wrote:
Раз не справляется, значит что-то криво. Схему таблицы и план
выполнения
покажите. Сколько одновременных пользователей и какой пул БД
используете?
порядка 10-20 активных соединений,
пример плана выполнения запросов:
dbmail=# explain SELECT message_idnr+1 FROM dbmail_messages WHERE
mailbox_idnr=37 ORDER BY message_idnr DESC LIMIT 1;
QUERY PLAN
--
Limit (cost=0.00..24.98 rows=1 width=8)
-> Index Scan Backward using dbmail_messages_pkey on
dbmail_messages (cost=0.00..78500.38 rows=3142 width=8)
Filter: (mailbox_idnr = 37)
(записей: 3)
dbmail=# explain SELECT message_idnr FROM dbmail_messages m JOIN
dbmail_physmessage p ON m.physmessage_id=p.id JOIN dbmail_headervalue
v on v.physmessage_id=p.id WHERE mailbox_idnr = 645 AND status IN
(0,1) AND headervalue ILIKE '%charsettest%' ORDER BY message_idnr;
QUERY PLAN
Sort (cost=840683.09..840683.10 rows=1 width=8)
Sort Key: m.message_idnr
-> Nested Loop (cost=0.00..840683.08 rows=1 width=8)
-> Nested Loop (cost=0.00..840679.66 rows=1 width=24)
-> Seq Scan on dbmail_headervalue v
(cost=0.00..840669.16 rows=3 width=8)
Filter: (headervalue ~~* '%charsettest%'::text)
-> Index Scan using dbmail_messages_2 on
dbmail_messages m (cost=0.00..3.49 rows=1 width=16)
Index Cond: (v.physmessage_id = m.physmessage_id)
Filter: ((mailbox_idnr = 645) AND (status = ANY
('{0,1}'::integer[])))
-> Index Scan using dbmail_physmessage_pkey on
dbmail_physmessage p (cost=0.00..3.41 rows=1 width=8)
Index Cond: (m.physmessage_id = p.id)
(записей: 11)
postgresql конечно 8.2 а не 8.3 :)
конфиг примерно такой:
max_connections = 500
shared_buffers = 512MB
work_mem = 256MB
maintenance_work_mem = 512MB
max_stack_depth = 5MB
max_fsm_pages = 204800
max_fsm_relations = 1
vacuum_cost_delay = 50 # 0-1000 milliseconds
bgwriter_delay = 200ms # 10-1ms between rounds
bgwriter_lru_percent = 20.0 # 0-100% of LRU buffers
scanned/round
bgwriter_lru_maxpages = 100 # 0-1000 buffers max written/
round
bgwriter_all_percent = 3# 0-100% of all buffers
scanned/round
bgwriter_all_maxpages = 600 # 0-1000 buffers max written/
round
fsync = on # turns forced
synchronization on or off
wal_sync_method = fdatasync # the default is the first
option
enable_seqscan = on
random_page_cost = 1.5 # same scale as above
effective_cache_size = 512MB
я не думаю что тут проблема в структуре / настройках бд - скорее в
запросах :)
бд сервер - 2 х Intel(R) Xeon(TM) CPU 2.66GHz, 2Gb RAM, диски scsi
На таком железе терабайтную базу гонять можно.
Как обычно - смотря какие запросы :)
Впрочем меня всегда интересовал вопрос как они вообще живут эти
террабайтный базы в реальной жизни.
Алексей Бещёков
[EMAIL PROTECTED]
+7 495 7853149
smime.p7s
Description: S/MIME cryptographic signature
Re: DBMail
> Почти перевёл почтовую базу на dbmail > не всё ещё проимпортировалось, но пока: > 30Gb, 1.6М писем, 6000+ пользователей > imap - не живёт :) бд (postgresql, 8.3) не справляется, хотя оттюнена > на подобную нагрузку. > все imap обращщения заканчиваются запросами вида > SELECT message_idnr+1 FROM dbmail_messages WHERE mailbox_idnr=82 > ORDER BY message_idnr DESC LIMIT 1 > которые висят по пол часа :) Раз не справляется, значит что-то криво. Схему таблицы и план выполнения покажите. Сколько одновременных пользователей и какой пул БД используете? > > что будет когда письма импортируются все (x2) - не хочется даже думать. > но видимо придётся переписывать запросы / делать триггеры / жёстко всё > оптимизировать. > > бд сервер - 2 х Intel(R) Xeon(TM) CPU 2.66GHz, 2Gb RAM, диски scsi На таком железе терабайтную базу гонять можно.
Re: DBMail
On 11/21/06, Alexey Lobanov <[EMAIL PROTECTED]> wrote: Hi all. On 21/11/06 04:08, proforg wrote: >> А вы не проводили нагрузочных тестов его? У меня Dbmail 2.1 при попытке >> вычитать IMAP-папку со 100К писем по несколько килобайт приказывал долго >> жить. Сервер был о 2Гб памяти, и dbmail сжирал её всю, уходил в своп, а >> потом и падал. Письма хранились в Postgres'e на этой же машине. > А как вел себя в этой ситуации тот же courier ? У меня самый толстый рабочий фолдер в Cyrus'е - 31К мелких писем, архив некоей рассылки. Проверил: сплошной полнотекстовый поиск по русскому слову в локальной сети около 20 секунд, "71 matches found". Сервер P4-2GHz, 1G памяти, файловая система Reiser 3. Память не отжирал никто. Раньше этот же архив (20К на тот момент) лежал на домашнем сервере с P1-133MHz, 64M, ext3. Работало, естественно, помедленнее, но сдохнуть не пыталось. 100К - надо бы нагенерировать и попробовать... А.Л. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] Возвращщаясь к старой теме. Почти перевёл почтовую базу на dbmail не всё ещё проимпортировалось, но пока: 30Gb, 1.6М писем, 6000+ пользователей imap - не живёт :) бд (postgresql, 8.3) не справляется, хотя оттюнена на подобную нагрузку. все imap обращщения заканчиваются запросами вида SELECT message_idnr+1 FROM dbmail_messages WHERE mailbox_idnr=82 ORDER BY message_idnr DESC LIMIT 1 которые висят по пол часа :) что будет когда письма импортируются все (x2) - не хочется даже думать. но видимо придётся переписывать запросы / делать триггеры / жёстко всё оптимизировать. бд сервер - 2 х Intel(R) Xeon(TM) CPU 2.66GHz, 2Gb RAM, диски scsi -- Alexej Bestchiokov EMail/JID: [EMAIL PROTECTED] phone: +7 495 7853149
Re: DBMail
Samoylov Mihail wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 sergio wrote: Vladimir Prohorov wrote: Здравствуйте, debian-russian. Пользовался ли кто этим чудом? Почему это чудом? Ну я пользуюсь, и что? -- Sergio. А вы не проводили нагрузочных тестов его? У меня Dbmail 2.1 при попытке вычитать IMAP-папку со 100К писем по несколько килобайт приказывал долго жить. Сервер был о 2Гб памяти, и dbmail сжирал её всю, уходил в своп, а потом и падал. Письма хранились в Postgres'e на этой же машине. А я не пользуюсь нестабильным софтом на сервере. у меня 2.0 и всё работает. -- Sergio. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DBMail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 sergio wrote: > Vladimir Prohorov wrote: >> Здравствуйте, debian-russian. >> >> Пользовался ли кто этим чудом? > > Почему это чудом? > Ну я пользуюсь, и что? > > -- > Sergio. > > А вы не проводили нагрузочных тестов его? У меня Dbmail 2.1 при попытке вычитать IMAP-папку со 100К писем по несколько килобайт приказывал долго жить. Сервер был о 2Гб памяти, и dbmail сжирал её всю, уходил в своп, а потом и падал. Письма хранились в Postgres'e на этой же машине. - -- С уважением, Самойлов Михаил, -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFXu+ZJgBoo5/qW1sRAq/2AJ9/4d5rmdCO5Cn3uwrIuZ+VROYkDwCfQXs6 yyBkeQr00rbKBUpuFakaf/k= =P1Z6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DBMail
Vladimir Prohorov wrote: Здравствуйте, debian-russian. Пользовался ли кто этим чудом? Почему это чудом? Ну я пользуюсь, и что? -- Sergio. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
DBMail
Здравствуйте, debian-russian. Пользовался ли кто этим чудом? DBMail is made up of several components. A normal MTA (Postfix, SendMail, QMail, Exim) is used for accepting messages. The MTA hands the messages over to dbmail-smtp, using a pipe interface, or dbmail-lmtpd, using LMTP (Local Mail Transport Protocol). These programs take care of delivering the message into the database. Messages can be retreived from the database using dbmail-pop3d, using the POP3 protocol, and dbmail-imapd, using the IMAP4Rev1 protocol. The whole email is stored in the database. That includes attachments. The DBMail programs do not have to touch the filesystem to retreive or insert emails. User information is also stored in the database, so users do not need an account on the machines DBMail is running on. deb http://debian.nfgd.net/debian unstable|experimental main -- С уважением, Vladimir mailto:[EMAIL PROTECTED]
Re: Религиозная война IMAP серверов. Cyrus vs Courier vs Dovecot vs dbmail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Teslenko wrote: > Приветствую, коллеги. > > Недавно поднимал этот вопрос, но ответов было гораздо меньше, чем про > "хранилище почты". > И, все-таки... Какой выбрать? Юзеров хочу полностью завиртуалить и > засунуть в LDAP. > Доброго дня. А давайте добавим сюда ещё "vs dbmail". Кто-нибудь его в production использует? - -- С уважением, Самойлов Михаил, -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFVFfvJgBoo5/qW1sRAiBoAJ48IvgGvrFFGwpWDSGBQbQhod3m3ACfcyZw jBiFYwk1JITyEF4LE03j3KQ= =dRgK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
exim4 & dbmail
есть dbmail'овский пользователь. у него есть куча алясов. В
thunderbird'е они записаны как identities для этого сервера.
хочу: если письмо отправляется на определённый адрес и с одного из
адресов принадлежажих пользователю чтобы from менялся бы на определённый
адрес.
вот одно из решений: в транспорт написать:
headers_rewrite = * "${if and{{eq{${lookup mysql{(SELECT userid FROM
dbmail_users WHERE userid = '${quote_mysql:[EMAIL PROTECTED]') UNION
(SELECT userid FROM dbmail_users where user_idnr = (SELECT deliver_to
FROM dbmail_aliases WHERE alias =
'${quote_mysql:[EMAIL PROTECTED]'))[EMAIL PROTECTED]@sergio.spb.ru}
fail}" f
собсна тут написано, что если юзер -- sergio и to --
[EMAIL PROTECTED] -- то поменять from на [EMAIL PROTECTED]
но
0) это не работает. я не знаю почему ): ( unknown rewrite flag character
'(' (could be missing quotes round replacement
item) )
1) это не красивое решение, красиво было бы через фильтры, но на сколько
я понимаю в фильтрах нельзя обращаться к mysql...
Sergio.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dbmail 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Никто не знает, есть-ли бэкпорты dbmail 2.0 для Саржа? - -- Sergio. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQwCrQpsR/RHJrAUrAQL6ewQArhy/QEXl04fh/vGJlmDd3YYzi9QTpmCt Oi/Z3/9y01PO+JAeRX574RU+MDWJMBom4A2G3naZTIX4mCqN64qDfBdcQoRfYcei Naql9tLW4qQ/qyOXTunl6CgFDPSM5shtpqggtuni1Q2lvfnkDyyGpxPdt6KnPTpf H8WCZBkrVhA= =4Q5w -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
