natan:
> W dniu 17.01.2022 o?15:58, Wietse Venema pisze:
> > natan:
> >> W dniu 14.01.2022 o 22:18, Wietse Venema pisze:
> >>> natan:
> >>> Wietse:
> >>>> Do you know if the problem is a kernel limit or a per-process limit?
> >>>> Does master have 4096 open files (including network sockets: ip,
> >>>> unix-domain, etc.).
> >>> Wietse:
> >>>> BTW that last one was a trick question: you need a huge number of
> >>>> services in master.cf to exceed the 4096 limit. The master needs
> >>>> three sockets for each service with type 'unix' in master.cf;
> >>>> services with type 'inet' require two sockets plus one socket per
> >>>> address in inet_interfaces.
> >>> natan:
> >>>> "Do you know if the problem is a kernel limit or a per-process limit?"
> >>>>
> >>>> I realy dont known where is it the problem - and how diagnose this
> >>>>
> >>>> I long think about kernel limit but ... no have idea
> > Wietse:
> >> Were you the person who has a Postfix process limit in the thousands?
> >> If that is the case, then I suggest that you reduce the Postfix
> >> process limit to half the number, do "postfix reload", wait for a
> >> while, and keep reducing the limit to half its value until the
> >> "resource temporarily unavailable" warnings go away. Also, make
> >> arrangements for more (and more powerful) servers.
> > natan:
> >> I don't know if I am that man with limit thousands
> >>
> >> # postconf -nf
> > ...
> >> default_process_limit = 1200
> >>
> >> from log:
> >> Jan 17 10:10:50 thebe4b postfix/postscreen[7103]: warning: cannot
> >> connect to service private/smtpd: Resource temporarily unavailable
> > postscreen maintains queues with connetions that still need to be
> > 'tested' (postscreen_pre_queue_limit) and that need to be given to
> > an smtpd process (postscreen_post_queue_limit).
> >
> > Each postscreen queue size is $default_process_limit. Both queues
> > together add up to 2400 network sockets.
> >
> > If you make this amount the same as your internet-facing smtpd
> > process limits, then postscreen might leave more resources for the
> > rest of Postfix.
> >
> > And then, reduce process limits by half and do "postfix reload",
> > until the 'Resource temporarily unavailable' message goes away.
> >
> >> This is a strong machine where load average: 0,95, 1,19, 2,08
> > Obviously, it doesn't use much CPU power when it can't create a
> > UNIX-domain socket.
> >
> > Wietse
> #for no scan amavis:
> 10.0.100.24/32 FILTER smtp:10.0.100.5:10025
> xxx.xxx.xxx.25/32 FILTER smtp:10.0.100.5:10025
> #go to amavis-klaster
> 0.0.0.0/0 FILTER smtp-amavis:[127.0.0.1]:10628
> ##########
OK, you're switching between after-queue content filters,
and there is no smtpd_proxy_filter.
That leaves the possibility that postscreen is hogging too many
network sockets.
Reduce the default_process_limit to the same number as your "smtpd
pass" service (currently, 190). Then do "postfix reload", and wait
for some time.
While Postfix logs "resource temporarily unavailable":
Halve the process limit for the "smtpd pass" SMTP service.
Halve the default_process_limit.
Do "postfix reload".
Wait for some time.
Wietse
