root soft nofile 65535 root hard nofile 65535 nobody soft nofile 65535 nobody hard nofile 65535
Все работает нормально.
Предложенные варианты с увеличением worker_processes и worker_connections в конфиге nginx - это дополнение к варианту svyazist или замена ему? Если замена, то какой способ более эффективный?
netwind: Почему вы думаете, что это вам даст возможность решать проблемы с сервером в будущем?
Потому, что это не первая возникшая проблема на сервере и другие, которые мне однажды удалось победить, больше меня не мучают. т.к. я сними быстро расправляюсь сам...
А проблемы обычно возникают у меня при смене сервера... вот сейчас как раз, очередной случай...
[root@katushka ~]# time host -t A katushka.net 85.17.92.39
Using domain server:
Name: 85.17.92.39
Address: 85.17.92.39#53
Aliases:
katushka.net has address 85.17.92.39
real 0m0.044s
user 0m0.002s
sys 0m0.004s
[root@katushka ~]# time host -t A katushka.net 4.2.2.1
Using domain server:
Name: 4.2.2.1
Address: 4.2.2.1#53
Aliases:
katushka.net has address 85.17.92.39
real 0m0.107s
user 0m0.000s
sys 0m0.003s
[root@katushka ~]# time host -t A google.com 85.17.92.39
Using domain server:
Name: 85.17.92.39
Address: 85.17.92.39#53
Aliases:
google.com has address 74.125.45.100
google.com has address 74.125.67.100
google.com has address 209.85.171.100
real 0m0.015s
user 0m0.003s
sys 0m0.002s
[root@katushka ~]# time host -t A google.com 4.2.2.1
Using domain server:
Name: 4.2.2.1
Address: 4.2.2.1#53
Aliases:
google.com has address 209.85.171.100
google.com has address 74.125.45.100
google.com has address 74.125.67.100
real 0m0.015s
user 0m0.002s
sys 0m0.002s
[root@katushka ~]# time host -t PTR 85.17.92.39
39.92.17.85.in-addr.arpa domain name pointer katushka.net.
real 0m0.012s
user 0m0.002s
sys 0m0.002s
[root@katushka ~]#
sysctl:
P.S. А вообще Вам нужно нанять админа который быстро диагностирует и исправит проблему за скромную плату, благо тут полно фрилансеров.
Если найму админа, то при повторном возникновении данной проблемы, я не смогу самостоятельно её решить. Поэтому мне самому хочется разобраться, что бы в будущем иметь возможность самостоятельно исправлять данную проблему.
# You can put comments anywhere you want to. They are effective for the # rest of the line.
# this is in the format of <name> = <value>. Whitespace at the beginning # and end of the lines is removed. Whitespace before and after the = sign # is removed. Everything is case *insensitive*.
# Yes = True = On = 1 # No = False = Off = 0
Title = "sendmail"
# Which logfile group... LogFile = maillog
# Only give lines pertaining to the sendmail service... *MultiService = sendmail,sm-mta *RemoveHeaders
# Previous versions of sendmail.conf allowed for the use of the # $Sendmail_Detail variable. Because now all services have use # of the Detail variable, $Sendmail_Detail is deprecated, and may # be removed in a future version of the sendmail filter script. # How Detail affects the output of sendmail is described here: # # The Detail is used to override the general logwatch Detail # parameter that is set either when invoking logwatch (option --detail) # or specified in the conf/logwatch.conf file, in the variable Detail. # If not specified, the default is to inherit the value of the general # logwatch Detail setting. # # Example: #Detail = 5 # # The defined values of Detail are as follows: # Detail >= 0: Will print:"; # - severe errors and basic statistics"; # Detail >= 3: Print above plus:"; # - counts of errors handled by sendmail"; # Detail >= 5: Print above plus:"; # - details of errors handled by sendmail"; # Detail >= 10: Print above plus:"; # - all statistics gathered";
# Note that Detail is independent of sendmail's LogLevel. # The logwatch script should be able to handle any logging level # set in sendmail (either through confLOG_LEVEL in the *.mc files # or through LogLevel in the *.cf files). The default setting is # usually a LogLevel of 9. At level 15, for example, SMTP # transactions are logged, and the logwatch script extracts additional # information. Levels above 15 generate additional debug information, # which is filtered by the logwatch script. Therefore, setting higher # levels of LogLevel will yield larger mail log files, may provide # additional parsed information in the logwatch log, but should not # cause new unmatched entries.
# All sendmail log statements that start with "DEBUG: " will be filtered. # This may be used for user-defined statements that should appear on the log, # but not reported by logwatch.
# $Sendmail_PrettyHost is used to format host entries in a tabular # format. It is mostly useful when you have a very large number of # entries for errors that display host names/addresses. If not # specified, the default is 0, which indicates that no additional # host formatting is done. Set to 1 to enable the host formatting. #$Sendmail_PrettyHost = 0
# The following are examples of the use of variables SendmailMatchFilter, # Sendmail_ReportFilter, and $Sendmail_MilterHeadersToCount. # To uncomment and use these specific examples, remember to remove the '#' # from the first column. And of course, you can write your own filters. # Note that unlike the statements in the sendmail script, you must end # each line (except the last one) with a \ to denote a continuation line
#$Sendmail_MatchFilter = " \ # # filter and count how many times the alias database is rebuilt \ # if ( ($User) = ($ThisLine =~ /^alias database .* rebuilt by (.*)/ ) ) { \ # $DatabaseBuild{$User}++; \ # # note that we don't need to re-assign an empty string to $ThisLine \ # # because the 'alias database' line is then ignored by the \ # # scripts/services/sendmail script. \ # } \ # \ # # here we'll choose to ignore and not report the 'lost input channel' \ # # statements \ # if ( $ThisLine =~ /^lost input channel from/ ) { \ # # we re-assign an empty string to $ThisLine to prevent further \ # # processing of this log line by the sendmail script. \ # $ThisLine = ""; \ # }"
# The $Sendmail_MilterHeadersToCount will count every header added with # one (or more) of the specified strings. Each string is specified by # delimiting it with a vertical bar, and is counted separately: $Sendmail_MilterHeadersToCount = "X-SPF|X-Spam|X-Scanned-By: MIMEDefang|Received-SPF: fail|Received-SPF: softfail"
######################################################### # Sendmail Threshold values. # These allow you to configure the output and restrict verbose reports # by limiting what is printed to occurances >= the value you enter. # # Note that case is insensitive.
Ну и толку, что я нанял админа? Потратил только время и деньги, а результата так и не добился никакого...
Еще раз убедился в высказывании: "если хочешь, что бы работа была сделана хорошо - сделай её сам".
В общем опыт сотрудничества отрицательный
KernelMadness, спасибо за помощь
Посещаемость у вас какая и какой характер нагрузки ? Тогда можно регулировать эти параметры.
~100.000 хитов, ~10.000 хостов / сутки
worker_rlimit_nofile 80000;
...
worker_connections 50000;
От таких больших значений, не будет повышенной нагрузки на сервер, ресурсов не будет больше есть? Или тут так, чем больше тем лучше ?
Сейчас использую способ, предложенный svyazist
/etc/security/limits.conf
приведите к виду
root soft nofile 65535
root hard nofile 65535
nobody soft nofile 65535
nobody hard nofile 65535
Все работает нормально.
Предложенные варианты с увеличением worker_processes и worker_connections в конфиге nginx - это дополнение к варианту svyazist или замена ему? Если замена, то какой способ более эффективный?
Почему вы думаете, что это вам даст возможность решать проблемы с сервером в будущем?
Потому, что это не первая возникшая проблема на сервере и другие, которые мне однажды удалось победить, больше меня не мучают. т.к. я сними быстро расправляюсь сам...
А проблемы обычно возникают у меня при смене сервера... вот сейчас как раз, очередной случай...
Что-то типа такого:
P.S. А вообще Вам нужно нанять админа который быстро диагностирует и исправит проблему за скромную плату, благо тут полно фрилансеров.
Если найму админа, то при повторном возникновении данной проблемы, я не смогу самостоятельно её решить. Поэтому мне самому хочется разобраться, что бы в будущем иметь возможность самостоятельно исправлять данную проблему.
какая у Вас ОС?
CentOS 5
что выводит #dig yourhostname?
проверьте время резолва доменов через nslookup
Поясните, пожалуйста, немного не понял...
Могут быть проблемы с преобразованием доменов в ip-адреса.
По этой причине могут быть "тормоза" при отправке почты.
И как эту проблему исправить?
maxttor добавил 23.02.2009 в 20:31
Конфиг sendmail'а:
Если сервер свой, то тогда только DNS.
А какие могут быть проблемы в ДНС ?