Добрый день, уважаемые пользователи хабра, несмотря на тенденцию падения Oracle в глазах системных инженеров и компаний-заказчиков.
Операционная система, теперь Oracle Solaris, продолжает жить и радовать наш глаз.
Недавно я столкнулся с проблемой оптимизации некоторых параметров стека TCP/IP. Эта тема показалась мне интересной; для многих это может показаться избитым, но для других это откроет новые интересные аспекты настройки.
Итак, начнем… Во-первых, давайте посмотрим на два параметра: tcp_conn_req_max_q И tcp_conn_req_max_q0 , зачем они вообще нужны, какие значения этих параметров наиболее подходящие.
Говоря простым языком, эти параметры отвечают за максимальное количество запросов на один IP-адрес и на порт, которые будут обрабатываться сервером.
tcp_conn_req_max_q — это максимальное количество входящих соединений, которые будет обработан портом.
tcp_conn_req_max_q0 — это максимальное количество «полуоткрытых» TCP-сессий, которые могут существовать на порту.
Эти параметры в Solaris позволяют администратору гарантировать блокировку пакетов SYN для предотвращения атак «отказ в обслуживании» в обычной DOS. Значение по умолчанию для параметра tcp_conn_req_max_q на Солярисе их всего 128, а для параметра tcp_conn_req_max_q0 1024. Этих параметров в принципе достаточно для сервера, обслуживающего небольшое количество клиентов, но если ожидается, что сервер будет получать больше запросов, чем указано по умолчанию, это существенно попортит нервы сисадмину.
Сначала это выглядит примерно так.
Когда приходит момент изменить эти параметры, определить это на самом деле довольно просто; если количество отброшенных пакетов зашкаливает, значит, время пришло.root@T1000-spare # ndd /dev/tcp tcp_conn_req_max_q 128 root@T1000-spare # ndd /dev/tcp tcp_conn_req_max_q0 1024
Как определить это количество, воспользуемся обычной пробой: root@T1000-spare # netstat -s | fgrep -i listendrop
tcpListenDrop = 0 tcpListenDropQ0 = 0
sctpListenDrop = 0 sctpInClosed = 0
В моем случае здесь нули, так как тестовый сервер не может показать изменение значений.
Но схема такая: если значение tcpListenDrop не равно нулю, мы увеличиваем tcp_conn_req_max_q, а если tcpListenDropQ0 ненулевое, мы соответственно увеличиваем значение параметра tcp_conn_req_max_q0. Но, есть одно НО, если сразу сильно увеличить tcp_conn_req_max_q, то он естественно будет уязвим для DOS, использующего SYN-пакеты.
Именно поэтому нам нужен второй параметр, который идеально создан для предотвращения подобных случаев.
Второй параметр отвечает за сессии, которые будут поставлены в очередь на сервере после получения пакета SYN. К сожалению, увеличить его размерно тоже нельзя, так как если приложение работает медленно, клиенты попадут в очередь и останутся там, так и не подключившись к серверу.
Любые изменения этих значений легко осуществить с помощью команды ndd. В качестве примера приведу значения одного из высоконагруженных серверов; эти параметры можно использовать в работе: # ndd -set /dev/tcp tcp_conn_req_max_q 16384 <====
# ndd -set /dev/tcp tcp_conn_req_max_q0 16384 <====
# ndd -set /dev/tcp tcp_max_buf 4194304
# ndd -set /dev/tcp tcp_cwnd_max 2097152
# ndd -set /dev/tcp tcp_recv_hiwat 400000
# ndd -set /dev/tcp tcp_xmit_hiwat 400000
В заключение об этих параметрах хотелось бы сказать, что к изменению этих параметров нужно относиться с должной осторожностью и не менять их без надобности.
P.S. Если кого-то интересуют другие параметры, их можно будет описать в следующей статье.
Спасибо за внимание.
Теги: #оптимизация сервера #tcp #IP #настройка #Solaris
-
Детекторы Частиц
19 Oct, 24 -
Авалония Мои Плюсы И Минусы
19 Oct, 24 -
Как Отследить Копирование Контента?
19 Oct, 24 -
Компьютерный Вирус – Желание Живого?
19 Oct, 24
