[ОТВЕТИТЬ]
Опции темы
24.03.2014 18:41  
OlegON
В общем, очередной раз меня почему-то проплющило на тему расковыривания параметров. Сейчас у меня так на форуме:
Цитата:
fs.file-max = 262144
kernel.msgmax = 65536
kernel.msgmnb = 65536
kernel.panic = 3
kernel.sem = 1250 256000 100 1024
kernel.shmall = 1048576
kernel.shmmax = 4294967296
net.core.netdev_max_backlog = 5000
net.core.optmem_max = 65536
net.core.rmem_max = 16777216
net.core.somaxconn = 10000
net.core.wmem_max = 16777216
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.default.log_martians = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.eth1.accept_source_route = 0
net.ipv4.ip_forward = 1
net.ipv4.ip_local_port_range = 28000 65500
net.ipv4.neigh.default.gc_thresh1 = 32
net.ipv4.neigh.default.gc_thresh2 = 1024
net.ipv4.neigh.default.gc_thresh3 = 2048
net.ipv4.neigh.default.proxy_qlen = 96
net.ipv4.neigh.default.unres_qlen = 6
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_max_orphans = 16384
net.ipv4.tcp_max_syn_backlog = 30000
net.ipv4.tcp_max_tw_buckets = 500000
net.ipv4.tcp_mtu_probing = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_tw_reuse = 1
net.ipv4.udp_rmem_min = 8192
net.ipv4.udp_wmem_min = 8192
net.netfilter.nf_conntrack_max = 131070
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 15
net.nf_conntrack_max = 131070
net.unix.max_dgram_qlen = 50
vm.dirty_background_ratio = 80
vm.dirty_expire_centisecs = 6000
vm.dirty_ratio = 90
vm.dirty_writeback_centisecs = 4000
и при старте системы
Цитата:
#ifconfig eth0 mtu 9000
#ifconfig eth1 mtu 9000
ifconfig eth0 txqueuelen 5000
ifconfig eth1 txqueuelen 5000

defrt=`ip route | grep "^default" | head -1`
ip route change $defrt initcwnd 10
специально не убирал закомментированное MTU, поскольку пытался использовать Jumbo frames, но в результате поперла фрагментация пакетов
Цитата:
ethtool -S eth1
NIC statistics:
rx_packets: 7051977
tx_packets: 6689955
rx_bytes: 3801136843
tx_bytes: 5380011205
rx_broadcast: 0
tx_broadcast: 38
rx_multicast: 0
tx_multicast: 0
rx_errors: 0
tx_errors: 0
tx_dropped: 0
multicast: 0
collisions: 0
rx_length_errors: 0
rx_over_errors: 0
rx_crc_errors: 0
rx_frame_errors: 0
rx_no_buffer_count: 0
rx_missed_errors: 0
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_fifo_errors: 0
tx_heartbeat_errors: 0
tx_window_errors: 0
tx_abort_late_coll: 0
tx_deferred_ok: 0
tx_single_coll_ok: 0
tx_multi_coll_ok: 0
tx_timeout_count: 0
tx_restart_queue: 0
rx_long_length_errors: 0
rx_short_length_errors: 0
rx_align_errors: 0
tx_tcp_seg_good: 0
tx_tcp_seg_failed: 0
rx_flow_control_xon: 0
rx_flow_control_xoff: 0
tx_flow_control_xon: 0
tx_flow_control_xoff: 0
rx_csum_offload_good: 7051234
rx_csum_offload_errors: 7
rx_header_split: 0
alloc_rx_buff_failed: 0
tx_smbus: 0
rx_smbus: 0
dropped_smbus: 0
rx_dma_failed: 0
tx_dma_failed: 0
rx_hwtstamp_cleared: 0
uncorr_ecc_errors: 0
corr_ecc_errors: 0
выделенное (сейчас 0) при увеличении MTU просто накручивалось почти равным общему количеству пакетов. Т.е. у провайдера эти Jumbo frames просто не поддерживались.
 
24.03.2014 18:53  
OlegON
В конфиге однозначно много мусора и как-нибудь я доберусь его почистить. Собственно, я и начал сначала сокращать большинство параметров в сторону "по умолчанию", но в итоге получил значительную деградацию производительности, после чего увеличил количество параметров почти втрое :)
Да, насчет конфигурации ядра. Если вы помните, я в свое время рекламировал congestion control HTCP, действительно классная и хорошо работающая штука, но, поскольку от версий ядер, где были ошибки у cubic, я ушел, то решил все же использовать более распространенное, т.е. сейчас у меня скомпилирован только кубик и разницы с HTCP не видно, повторяю: net.ipv4.tcp_congestion_control = cubic. Вернул просто, чтобы было ближе к умолчательному варианту, но можно и оставить, если не забывать, что оно там есть и когда-то может устареть или работать хуже.
Второй нюанс в конфиге ядра - CONFIG_HZ_250, именно такой он у меня сейчас и установлен. Долгое время был CONFIG_HZ_100, и, хотя видимого изменения быстродействия самого сервера я не замечал, при CONFIG_HZ_250 LA (load average) все время болтается в 3-4, а при CONFIG_HZ_100 - 5-7. Нервировало, хотя, скорее всего, это просто огрехи подсчета LA. Оставил CONFIG_HZ_250.
Парадоксально, но задранные (на мой взгляд) до полумиллиона значения действительно дают эффект. Но, тем не менее, выставлять rmem_default и аналогичные размеры буферов не стоит. Достаточно минимум и максимум. Остальное все считается в автомате и на автомате работает лучше, чем с фиксированно установленными ручными значениями. По крайней мере я это анализировать не умею и натюнил только ухудшение. Выкинул то, что было во многих рекомендациях - стало быстрее.
vm.dirty* на быстродействие сети, понятно, не влияет. Копипастил, пока проблем нет - оставил, хотя это первые претенденты на вынос. В свое время воевал, помню, что были какие-то проблемы. Но это было еще на диске, сейчас SSD.
 
 
Опции темы



Часовой пояс GMT +3, время: 23:13.

Все в прочитанное - Календарь - RSS - - Карта - Вверх 👫 Яндекс.Метрика
Форум сделан на основе vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.