1.1, unk (ok), 13:23, 03/02/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
В конфигурациях с 2-мя и более MX'ами anvil(8) не может работать вообще. Для postfix 2.x такие ограничения лучше делать через check_policy_service.
| |
|
|
|
|
|
6.6, unk (ok), 14:14, 03/02/2005 [^] [^^] [^^^] [ответить]
| +/– |
>Посмотрел. Тоже, только на Си. Дергать СУБД на каждое письмо и держать
>специально для этого MySQL, не решение.
Т.е. хочется обойтись только кэшем?
| |
|
|
4.8, vasili (?), 15:20, 03/02/2005 [^] [^^] [^^^] [ответить]
| +/– |
не вижу ничего страшного в этом. сколько у тебя тысяч в день писем? | |
|
5.9, unk (ok), 15:26, 03/02/2005 [^] [^^] [^^^] [ответить]
| +/– |
>не вижу ничего страшного в этом. сколько у тебя тысяч в день
>писем?
Вы меня или Максима спрашиваете?
| |
5.10, Maxim Chirkov (ok), 15:36, 03/02/2005 [^] [^^] [^^^] [ответить]
| +/– |
>не вижу ничего страшного в этом. сколько у тебя тысяч в день
>писем?
Вчера было тысяч 300, на первом попоавшемся под руку релее :-)
Но дело не в этом, приход спама идет волнами, в пике сколько дашь - столько сожрут, к более сотни одновременным сесииям в момент рассылки спама я уже привык. Использовать для этого MySQL как стрелять из пушки по воробъям.
Что будет с вашей машиной при 150 висящих MySQL, главное сколько при этом потребуется памяти :-)
PS. Уже третий день наблюдаю как спамерские трояны по тупому перебирают адреса в одном домене, такие переборы дают прибавку в пару сотен Мб к размеру лога в день. Самое пакостное, что бороться с этим DDoS невозмонжно, адреса у каждого запроса разные :-(
| |
|
6.11, unk (ok), 16:00, 03/02/2005 [^] [^^] [^^^] [ответить]
| +/– |
>Вчера было тысяч 300, на первом попоавшемся под руку релее :-)
>Но дело не в этом, приход спама идет волнами, в пике сколько
>дашь - столько сожрут, к более сотни одновременным сесииям в момент
>рассылки спама я уже привык. Использовать для этого MySQL как стрелять
>из пушки по воробъям.
Это все чудесно, но речь то о лимитах для своих клиентов.
>Что будет с вашей машиной при 150 висящих MySQL, главное сколько
>при этом потребуется памяти :-)
Ни чего страшного. Для postfix это будет легче чем скажем cidr или hash.
| |
|
7.12, Maxim Chirkov (ok), 16:28, 03/02/2005 [^] [^^] [^^^] [ответить]
| +/– |
>Это все чудесно, но речь то о лимитах для своих клиентов.
А что, свои клиенты массой подхватив вирус не могут обеспечить такую нагрузку ?
>>Что будет с вашей машиной при 150 висящих MySQL, главное сколько
>>при этом потребуется памяти :-)
>Ни чего страшного. Для postfix это будет легче чем скажем cidr или
>hash.
Для postfix, но не для MySQL с разросшейся таблицей IP'шек. Пусть даже он будет держать целикиком ее в памяти - нагрузка от него будет горяздо больше, чем от postfix на том почтовом сервере. Итого имеем необходимость использовать монстра, из-за нежелания потратить пару часов на написание оптимального кода. Там где очень много параллельных update/insert MySQL дохнет и затыкается на локах.
| |
|
8.17, unk (ok), 16:58, 03/02/2005 [^] [^^] [^^^] [ответить] | +/– | Могут конечно, но я говорю это к тому, что выставив лимиты только для своих мы р... текст свёрнут, показать | |
|
|
10.21, unk (ok), 22:00, 03/02/2005 [^] [^^] [^^^] [ответить] | +/– | Что-то я вас не понимаю Вы считаете, что парсить лог дешевле, чем тем же самы... текст свёрнут, показать | |
|
|
12.23, unk (ok), 09:41, 04/02/2005 [^] [^^] [^^^] [ответить] | +/– | Нет Дальше лимита выставленного в master cf дело просто не пойдет Вот что у ва... текст свёрнут, показать | |
|
|
14.25, unk (ok), 11:24, 04/02/2005 [^] [^^] [^^^] [ответить] | +/– | Давайте считать, то что система настроена, иначе разговор не имеет смысла В это... текст свёрнут, показать | |
|
|
16.27, unk (ok), 13:55, 04/02/2005 [^] [^^] [^^^] [ответить] | +/– | Вас интересуют не лимиты для клиентов, а только борьба со флудом Мне же нужно л... текст свёрнут, показать | |
|
|
|
|
|
|
|
|
|
|
6.14, vasili (?), 16:38, 03/02/2005 [^] [^^] [^^^] [ответить]
| +/– |
>Вчера было тысяч 300, на первом попоавшемся под руку релее :-)
>Но дело не в этом, приход спама идет волнами, в пике сколько
>дашь - столько сожрут, к более сотни одновременным сесииям в момент
>рассылки спама я уже привык. Использовать для этого MySQL как стрелять
>из пушки по воробъям.
>Что будет с вашей машиной при 150 висящих MySQL, главное сколько
>при этом потребуется памяти :-)
Да.... у меня 2000-3000 в день в обе стороны. MySQL справиться я так думаю :) Если объемы будут расти, то поставлю postgre или буду искать более быстрое решение без использования СУБД.
| |
|
|
|
|
|
|
2.19, mira (?), 19:13, 03/02/2005 [^] [^^] [^^^] [ответить]
| +/– |
Это через админ интерфейс
SMTP->Receiving->Limits
Non-Client Sender: Limited to:2 per: 30 seconds
Помойму так!
| |
|
1.15, mirya (?), 16:47, 03/02/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
может эффективнее было бы заодно и уведомлять клиента, что от него градом сыпется спам, т.е. приймите меры, т.к. спам-агент еще кроме первичной задачи ворует частную информацию, удаляет у вас все с диска Ж:, шкрябает сидюки, ламает колесико в мышке и т.д. - поставте 20 антивирусных програм, перезапустите винду 40 раз, отформатируте винт - 20... | |
1.16, robin zlobin (?), 16:48, 03/02/2005 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
всех спасет принудительный smtp auth :-)
я уже давно практикую на своих почтовых серверах обязательную аутентификацию на релеях. пользователи ничего, привыкнут. | |
|
2.18, mirya (?), 17:32, 03/02/2005 [^] [^^] [^^^] [ответить]
| +/– |
Ага, с расчетом на то, что клиент - параноик, и не хранит логин/пассворд в конфиге мейл-программы, а вводит его каждый раз ручонками. В конце концов даже при таком подходе можно доработать зебат, чтобы вместе с настоящим мылом юзверя отправлял пачку революционных листовок | |
|
3.28, Rick (??), 22:14, 04/02/2005 [^] [^^] [^^^] [ответить]
| +/– |
Ну, в таком случае, мы будем точно знать кто это, и либо свободен, либо антитроян + антивирус в студию. | |
|
|
|
|
3.31, zyxman (?), 01:52, 23/02/2005 [^] [^^] [^^^] [ответить]
| +/– |
Ребяты, откуда вы на самом деле такого низкого мнения о mysql?
я пару месяцев назад игрался с ним, и получил на _грамотно_постоенной_базе_ 200000 insert/s.
update-ов без перестроения ключей еще раз в 10 больше.
join по ключу на таблице 800000 записей отработался за 0.0004s.
Аккуратнее нужно подходить к базе данных, и все у вас получится.
| |
|
4.32, uldus (ok), 08:24, 23/02/2005 [^] [^^] [^^^] [ответить]
| +/– |
>я пару месяцев назад игрался с ним, и получил на _грамотно_постоенной_базе_ 200000
У вас нет понимания того, что ваши синтетические тесты в реальных ситациях малопригодны. Как пример, попробуте добавить ваши 200000 в 10-100 параллельных потоков, без отложенных insert'ов. С блокировками у MySQL не все в порядке.
> update-ов без перестроения ключей еще раз в 10 больше.
Апдейтов не может быть больше, так как update по сути это тот же insert. | |
|
|
|
|