> In /usr/include/bits/typesize.h on Linux boxes, __FD_SETSIZE is also
> defined. It seems to apear in several files. I'm not sure where
> changing is needed to make it work, and if a kernel recompile is also
> needed, since it's a low-level part of the OS. I'm also
> not usre if the hugemem k
In /usr/include/bits/typesize.h on Linux boxes, __FD_SETSIZE is also
defined. It seems to apear in several files. I'm not sure where
changing is needed to make it work, and if a kernel recompile is also
needed, since it's a low-level part of the OS. I'm also
not usre if the hugemem kernel offe
I tried to change
#define __FD_SETSIZE 1024
to
#ifndef __FD_SETSIZE
#define __FD_SETSIZE 1024
#endif
in /usr/include/bits/typesizes.h
and
#define __FD_SETSIZE 20480
in policyd.h
As I could see, that resolved the problem And I think these changes
are not correct :) May somebody pred
Finally, I think that the problem in
/usr/include/linux/posix_types.h, #define __FD_SETSIZE 1024
So, to solve the problem it's necessary to use several instances of
policyd or use method different from select().
Artem Bokhan ?:
> May developers test policyd with about 2k simultaneous tcp con
May developers test policyd with about 2k simultaneous tcp connections?
Just open them.
Tobias J. Kreidl ?:
> Hello, Artem:
>
> On Wed, 31 Oct 2007, Artem Bokhan wrote:
>
>
>> Hello again, I would like to return to the problem.
>>
>> After creating a lot of connections policyd stops to rec
Hello, Artem:
On Wed, 31 Oct 2007, Artem Bokhan wrote:
> Hello again, I would like to return to the problem.
>
> After creating a lot of connections policyd stops to receive new
> connections and use 100% of cpu.
> Connections was simulated with JMeter (1500 connections). Anybody can
> confirm th
Hello again, I would like to return to the problem.
After creating a lot of connections policyd stops to receive new
connections and use 100% of cpu.
Connections was simulated with JMeter (1500 connections). Anybody can
confirm the same behavior?
Ubuntu Dapper, uname -a
Linux 2.6.15-26-amd64-se
Le 7 sept. 07 à 18:03, Benny Pedersen a écrit :
On Fri, September 7, 2007 10:46, Xavier Beaudouin wrote:
How many concurrent smtpd processes do you have on your MX?
Up to 1.5k per MX in peak during bot attacks.
Hum. Anvil on postfix is a very good idea to avoid too mutch
ressources
utiliz
Benny Pedersen wrote:
> On Fri, September 7, 2007 10:46, Xavier Beaudouin wrote:
>
How many concurrent smtpd processes do you have on your MX?
>>> Up to 1.5k per MX in peak during bot attacks.
>>>
>> Hum. Anvil on postfix is a very good idea to avoid too mutch ressource
Xavier Beaudouin wrote:
> Hi,
>
>
>>> How many concurrent smtpd processes do you have on your MX?
>>>
>>>
>>>
>> Up to 1.5k per MX in peak during bot attacks.
>>
>
> Hum. Anvil on postfix is a very good idea to avoid too mutch ressources
> utilization.
>
> /Xavier
>
>
But anvi
In that case, there should at least be a comment in the start-up scripts
provided. :-) As root, it's usually a limit that you can easily
override and that would be done best in the startup script. Also, the
documentation
doesn't discuss the limit/file descriptor constraints really -- you sort
On Fri, September 7, 2007 10:46, Xavier Beaudouin wrote:
>>> How many concurrent smtpd processes do you have on your MX?
>> Up to 1.5k per MX in peak during bot attacks.
> Hum. Anvil on postfix is a very good idea to avoid too mutch ressources
> utilization.
there needs to be limit on smtpd_polic
Hi,
>> How many concurrent smtpd processes do you have on your MX?
>>
>>
> Up to 1.5k per MX in peak during bot attacks.
Hum. Anvil on postfix is a very good idea to avoid too mutch ressources
utilization.
/Xavier
-
This
> if you're limiting
> Policyd to 1024 in ulimit, can you really blame Policyd for its
> behavior?
>
>
I can't blame free software for anything : ) But usually software
reports about out of fds, and will still work after freeing some of them.
I would blame policyd's compilation for allowing more potential
file descriptors than most shells will by default -- unless it provided
extra code to warn users to make sure the file descriptor limit is first
raised. As mentioned before, it doesn't seem a good practice to so
readily make it possi
I think you need both -- in policyd.h, there is a parameter MAXFDS, that
has to be either picked up by the configuration or hard-coded. You can
try to increase the limit in the shell first and then recompile so it
picks up a higher limit. I'd add a limit/ulimit statement in the
startup script
Artem Bokhan wrote:
> I will play with ulimit (was 1024 :( ) first and wait until bots will
> wake up again :)
> May be it's possible to increase the limits by policyd instead of shell?..
There is no guarantee that Policyd's attempt to raise it will work.
I do recommend you do some kernel tuning
I will play with ulimit (was 1024 :( ) first and wait until bots will
wake up again :)
May be it's possible to increase the limits by policyd instead of shell?..
Cami Sardinha ?:
> Artem Bokhan wrote:
>
>> I'll try to change ulimit and possible MAXFD.
>> But it's still bad that policyd nee
Artem Bokhan wrote:
> I'll try to change ulimit and possible MAXFD.
> But it's still bad that policyd needs to be restarted after it reaches
> limit.
Artem,
Please downgrade to v1.80 and check/test if this still occurs.
Nigel, can you dig into this further?
-
r5 | nkukard | 2007-06-20 19:48:0
Sounds like recompiling with a larger number of file descriptors and
then running with a bigger limit/ulimit might do the trick. In any case,
the number of concurrent policyd file handles shouldn't be less
than the number of postfix instances on any given machine.
On Fri, 7 Sep 2007, Artem Bokhan
As I said, I don't have any bottlenecks with system resources.
Tobias J. Kreidl ?:
> Is policyd on the same machine as the DB server? If so, you may want to
> have your mySQL server on a different machine. If not, it sounds like you
> might have to spit your load among more than one mail
> Frankly, I think you'd have to have a pretty hefty amount of processing
> to run that many email connections plus policyd plus whatever else might
> be running on your mail server (amavisd, spamassassin, etc.) to sustain
> that kind of
> load.
I have two MXes with 4 cores of Xeon 5130 (2.0
I'll try to change ulimit and possible MAXFD.
But it's still bad that policyd needs to be restarted after it reaches
limit.
Cami Sardinha ?:
> Tobias J. Kreidl wrote:
>
>> So, in the case of 5k connections per minute, the server is probably
>> saturated... does policyd log that it's reach
Do you only have 1 machine as your MX?
I have two MXes each running its own policyd.
Do you run Policyd on
the same server as your MySQL database?
Mysqld located on first MX.
How many concurrent smtpd processes do you have on your MX?
Up to 1.5k per MX in peak during bot attacks.
I
Cami Sardinha wrote:
> Tobias J. Kreidl wrote:
>
>> So, in the case of 5k connections per minute, the server is probably
>> saturated... does policyd log that it's reached its limit?
>>
>
> Connections per minute do not mean much. Concurrent connections
> is what matters. It should log when
Tobias J. Kreidl wrote:
> So, in the case of 5k connections per minute, the server is probably
> saturated... does policyd log that it's reached its limit?
Connections per minute do not mean much. Concurrent connections
is what matters. It should log when its limit has been reached.
> If more con
So, in the case of 5k connections per minute, the server is probably
saturated... does policyd log that it's reached its limit?
If more connections are needed, one would of course have to
increase the file descriptor limit and recompile policyd according to
MAXFDS in policyd.h.
On Thu, 6 Sep 20
Tobias J. Kreidl wrote:
> Where is the maximum number of concurrent policyd processes defined?
> Is it defined/restricted by the limit of file descriptors?
Correct. Depending on your OS, ulimit -n will show the limit and
starting Policyd up in DEBUG=3 mode will show if its managed to
override that
Where is the maximum number of concurrent policyd processes defined?
Is it defined/restricted by the limit of file descriptors?
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems
Artem Bokhan wrote:
> Cami Sardinha ?:
>> What types of load?
>
> What do you mean? :) policyd begin to eat 100% of one cpu core, even
> after stopping postfix. The only way to fix that is restarting policyd.
Do you only have 1 machine as your MX? Do you run Policyd on
the same server as you
Cami Sardinha ?:
> Artem Bokhan wrote:
>
>> Under high load policyd (1.81) stalls with 100% cpu load and excessive
>> select() in strace
>> Any suggestions?
>>
>
> What types of load?
What do you mean? :) policyd begin to eat 100% of one cpu core, even
after stopping postfix. The
Is policyd on the same machine as the DB server? If so, you may want to
have your mySQL server on a different machine. If not, it sounds like you
might have to spit your load among more than one mail gateway. By the
way, policyd is built by default to handle up to 4096 processes, if I'm
not
Cami Sardinha ?:
> Artem Bokhan wrote:
>
>> Under high load policyd (1.81) stalls with 100% cpu load and excessive
>> select() in strace
>> Any suggestions?
>>
>
> What types of load?
What do you mean? :) policyd begin to eat 100% of one cpu core, even
after stopping postfix. The
How many concurrent postfix processes are allowed? What about
memory on the system -- are you swapping or not?
On Wed, 5 Sep 2007, Cami Sardinha wrote:
> Artem Bokhan wrote:
>> Under high load policyd (1.81) stalls with 100% cpu load and excessive
>> select() in strace
>> Any suggestions?
>
Artem Bokhan wrote:
> Under high load policyd (1.81) stalls with 100% cpu load and excessive
> select() in strace
> Any suggestions?
What types of load? Why are there so many concurrent connections open
to Policyd? What is the maximum amount of connections you've configured
Policyd to allow?
Under high load policyd (1.81) stalls with 100% cpu load and excessive
select() in strace
Any suggestions?
select(1025, [9 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
36 matches
Mail list logo
