Komunikazioen optimizazioa

i2basque(e)tik

Hona jo: nabigazioa, bilatu

Edukiak

Komunikazioen optimizazioa kalkulu trinkorako

Sistema eragileek komunikazioetan erabilitako aukerak kontserbadoreak izaten dira berez, funtzionamendu zuzena segurtatzeko, konfigurazioen eta sistemen aniztasun ahalik eta handienarekin.

Balio horiek azkar optimizatzeko modukoak dira, komunikazioetan errendimendu handiagoa lortzeko. Horretarako, oraingo errendimenduaren ebaluazioa eta oraingo balioen optimizazioa egin behar da, zenbait ataletan.


Oraingo errendimenduaren ebaluazioa

Sare batek konektaturiko sistemen arteko komunikazioen errendimendua ebaluatzeko tresna desberdinak daude. Tresnarik erabilienen zerrenda TCP Tuning-en dago.

i2BASQUE-en GRID sistemarako Iperf erabili dugu. Horren oinarrizko funtzionamendua oso erraza da. Adibide honetan, TCP komunikazioen abiadura neurtzen da, leihoen tamaina erabiliz, ondoko bi nodoen artean, Gasteizeko klusterrean.

vit1:~# iperf -s 
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:   256 KByte (default)
------------------------------------------------------------
[  4] local 10.0.2.2 port 5001 connected with 10.0.2.3 port 40651
[  4]  0.0-10.0 sec  1.09 GBytes    938 Mbits/sec
vit2:~# iperf -c vit1
------------------------------------------------------------
Client connecting to vit1, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 10.0.2.3 port 40651 connected with 10.0.2.2 port 5001
[  3]  0.0-10.0 sec  1.09 GBytes    938 Mbits/sec

Adibide honetan, Gasteizeko klusterreko vit1 nodoak zerbitzariaren lana egiten du, eta vit2 nodoa bertara konektatzen da neurketa egiteko. Ikusten denez, lotunearen errendimendua 938Mbp-koa da. Emaitza ona da, aintzat hartuta lotunea Gigabit ethernet-ekoa dela; gainera, proba egiteko unean sarea erabiltzen duten aplikazio batzuk daude. Proba egin baino lehen, bidezko optimizazioak egin dira.

TCP/IPren parametroen optimizazioa

TCP/IPren parametroen eta baterako sorkuntza kontrolatzeko algoritmoen optimizazioa ikertzeko gidaliburuak eta artikuluak daude. Honako erreferentzia hauek gomendatzen ditugu:

TCPren arazo nagusia emisio leihoaren tamaina egokia aukeratzea da, eta hori honako hau da teorian:

leihoaren tamaina = 2 * bandaren zabalera * atzerapena (edo delay)

Ping programak joan-etorriko aldia eskaintzen du (RTT edo Round Trip Time). Horren emaitza zuzen-zuzen erabil daiteke goiko formulan:

leihoaren tamaina  = bandaren zabalera  * RTT

Geure kasuan, ordezpena egin daiteke:

leihoaren tamaina = 1Gbps * 0,318ms = 125000KBps * 0,318e-3s = 39,75KB

Datu hau lortu ondoren, probak egin daitezke bufer tamaina desberdinekin, Iperf komandoa erabiliz:

vit1:~# iperf -s -w 39.75k                                                    
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 79.5 KByte (WARNING: requested 39.8 KByte)
------------------------------------------------------------
[  4] local 10.0.2.2 port 5001 connected with 10.0.2.3 port 40696
[  4]  0.0-10.0 sec    972 MBytes    816 Mbits/sec

vit2:~# iperf -c vit1 -w 39.75k
------------------------------------------------------------
Client connecting to vit1, TCP port 5001
TCP window size: 79.5 KByte (WARNING: requested 39.8 KByte)
------------------------------------------------------------
[  3] local 10.0.2.3 port 40696 connected with 10.0.2.2 port 5001
[  3]  0.0-10.0 sec    972 MBytes    816 Mbits/sec
  • Oharra: -w parametroa TCP leihoaren tamaina adierazteko da.

Ikusten denez, balio horren bidez lorturiko balioak ez dira inondik inora ere hobezinak. Balio askorekin probatu behar da, harik eta hobezinak lortu arte.

Halaber, TCP leihoa ez ezik, beste parametro batzuk ere alda daitezke. TCPren parametroen balio desberdinen aurkibidea dago Linux-en (man 7 tcp eginez) edo Linux man page for TCP(7) deritzonean. Era berean, TCP balioak optimizatzeko beste bide batzuk ere badira, adibidez, TCP Tuning Guide eta hori Linux-erako da, baina hortik beste sistema eragile batzuetan ere sar daiteke.

Aldatu ditugun balioak konfigurazioko /etc/sysctl.conf fitxategian daude':

vit1:~# more /etc/sysctl.conf
#
# /etc/sysctl.conf - Configuration file for setting system variables
# See sysctl.conf (5) for information.
#
# Be warned that /etc/init.d/procps is executed to set the following
# variables.  However, after that, /etc/init.d/networking sets some
# network options with builtin values.  These values may be overridden
# using /etc/network/options.

#kernel.domainname = example.com
#net/ipv4/icmp_echo_ignore_broadcasts=1
# increase TCP max buffer size
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# increase Linux autotuning TCP buffer limits
# min, default, and max number of bytes to use
#mejor entre distintos clusters iperf 902 112
#net.ipv4.tcp_rmem = 4096 87380 16777216 
#net.ipv4.tcp_wmem = 4096 65536 16777216
#mejor entre mismo cluster 942 27
net.ipv4.tcp_rmem = 4096 262144 16777216 
net.ipv4.tcp_wmem = 4096 16384 16777216
# don't cache ssthresh from previous connection
net.ipv4.tcp_no_metrics_save = 1
# recommended to increase this for 1000 BT or higher
net.core.netdev_max_backlog = 2500 

Balio horiek produkzioan jartzeko, sysctl tresna erabiltzen da, sysctl-p komandoaren bidez

Goiko konfigurazio fitxategian ikusten denez, net.core.rmem_max eta net.core.wmem_max balioak TCP leihoen gehieneko tamainei dagozkie.

  • Oharra: Linux-ek bikoiztu egiten du eskaturiko buffer-aren tamaina. Horrenbestez, goian jarri dugunak esan nahi du TCP leihoaren neurria 32MB-koa izango dela.

net.ipv4.tcp_rmen eta net.ipv4.tcp_wmem balioak TCP leihoen gutxieneko eta gehieneko balioei dagozkie, eta horiek egokitzen joango dira, itotzea kontrolatzeko erabiltzen diren algoritmoen arabera:

  • reno: TCP tradizionala, sistema eragilerik gehienetan erabiltzen dena (lehenetsiz)
  • bic: BIC-TCP
  • highspeed: HighSpeed TCP: Sally Floyd-ek iradokitako algoritmoa
  • htcp: Hamilton TCP
  • hybla: sateliteko lotuneetarako
  • scalable: TCP eskalagarria
  • vegas: TCP Vegas
  • westwood: pakete galera ugariko sareetarako optimizatuta

Halaber, net.ipv4.tcp_no_metrics_save = 1 ere balioan jarri da, konexio bakoitzerako bideen metriken datuak ez arakatzeko; balioen artean, aipagarriak dira RTT edo cwnd, etab.

net.core.netdes_max_backlog = 2500 balioak esan nahi du gehienez 2500 pakete prozesatuko direla, ethernet txartela jasotzeko ilaran daudenen artean, sareko paketea iritsi izanaren etena heltzen denean. Horren berezko balioa, sareko txartelik gehienetan, 300 da eta Gigabit txarteletarako (adibidez, geureak) edo 10Gigabit txarteletarako soilik aldatu beharko litzateke, 30000 balioa jarrita. Balioa handiegia edo txikiegia izateak ondorio txarrak izan ditzake errendimenduan.

Ethernet TCP/IP txartelen driverraren parametroen optimizazioa

Halaber, sareko txartelaren driverraren parametro batzuk manipula daitezke, errendimendua hobetzeko. Linuxerako, sareko txartelen driverrei buruzko dokumentazioaren oinarria Linux Network Drivers & Networking Utilities-en dago.

Geure Intel Gigabit PRO/1000MT sareko txartelentzat konfiguratzeko moduko parametroak honako honetan ikus daitezke: Networking and Communications: Advanced Settings Help File for Intel® Adapters. Linuxen aldatu ahal diren parametroak honako honetan daude: Networking and Communications: Linux* Base Driver.

Driverraren optimizazioari dagokionez, bi hurbiltze desberdin egin daitezke, bata CPUren gastua (nodo bakoitzean) murrizteko eta bestea sarearen errendimendua hobetzeko (latentzia murriztuta). Guk bigarrena aukeratu dugu; izan ere, ethernet motako sareen (askoz ere garestiagoak) eta MPI motako kalkulu zientifikorako diseinaturiko sareen (adibidez, Myrinet, askoz ere garestiagoak) errendimenduaren arazo nagusia latentzia da. Lehenengo aukera egokiagoa da nodo bakoitzeko prozesu bakarra exekutatuko duten klusterretan, nodo horrek CPU osoa kontsumitzen duenean eta kluster bereko beste nodo batzuekin komunikazio gutxi duenean. Gure kasuan, geure klusterretan MPI motako aplikazio paraleloak exekutatzen dira eta horien artean komunikazio handia dago; hain zuzen ere, mezuen latentzia ahalik eta gehien murriztu nahi izan da, geure Ethernet motako sarearen eta Myrinet-en artean dagoen errendimendu-distantzia laburtzeko.

Geure inguruari dagokionez, proba asko egin ditugu eta parametrorik egokienak /etc/modules.conf fitxategian aipaturikoak dira, sareko txartelari buruzkoak (sareko txartelari buruzko laburpena baino ez da jartzen):

options e1000 InterruptThrottleRate=0 RxIntDelay=0 TxIntDelay=0 RxAbsIntDelay=0 TxAbsIntDelay=0

Bestalde, e1000 driverrari ematen zaizkion aukeren esangura hauxe da, ordena erlatiboan:

  • InterruptThrottleRate=0: Representa el máximo número de interrupciones por segundo que genera el controlador de la tarjeta de red. Al ponerlo a 0 se desactiva, quiere decir que genera una por trama que se reciba de la red, las que hagan falta. Esto consume más procesador, ya que cada interrupción hace que la CPU tenga que ejecutar una rutina de interrupción, pero hará que cada trama llegue a su destino lo antes posible minimizando así la latencia de la red.
  • RxIntDelay=0: Sareko txartelaren kontrolatzaileak segundoko sortzen duen gehieneko eten kopurua adierazten du. 0-n jartzean desaktibatu egiten da, eta esan nahi du sarean jasotako trama bakoitzeko bat sortzen duela. Horrek prozesadore gehiago kontsumitzen du; izan ere, eten bakoitzaren eraginez, CPUk eten-errutina bat exekutatu behar du, baina horrela trama bakoitza ahalik eta arinen helduko da helmugara, sarearen latentzia minimizatuz.
  • TxIntDelay=0: Balio honek atzeratu egiten du etenen sorkuntza, 1024 mikrosegundoko unitateetan. Transmisioko etenen murriztapenak hobetu egin dezake CPUren kontsumoa, baldin eta hori ondo konfiguratzen bada sareko trafiko jakinerako. Balio horren hazkundeak latentzia gehitzen dio tramen harrerari eta, horrela, TCP trafikoaren errendimendua murriztu egin daiteke. Sistemak harrera desegokiak daudela jakinaraziz gero, balio hori altuegia izan daiteke, eta horrela, driverra memoria barik gera daiteke (trama gehiago jasotzeko). 0-n jartzean, trama bakoitza heltzean etena sortzen da eta berehala ematen da, CPU gehiago kontsumituz, baina latentzia murriztuta.
  • RxAbsIntDelay=0: Balio hau, aurrekoak bezala, 1024 mikrosegundoko unitateetan dator. Etena sortzeko atzerapena mugatzen du. RxIntDelay 0 ez denean soilik erabil daiteke; segurtatu egiten du etena adierazitako denbora kantitatean sortzen dela, lehenengo trama heldu ondoren. 0-n jartzean aditzera ematen du tramak lehenbailehen ematen direla.
  • TxAbsIntDelay=0: Balio hau, aurrekoak bezala, 1024 mikrosegundoko unitateetan dator. Etena sortzeko atzerapena mugatzen du. RxIntDelay 0 ez denean soilik erabil daiteke; segurtatu egiten du etena adierazitako denbora kantitatean sortzen dela, lehenengo trama kablez bidali ondoren. 0-n jartzean aditzera ematen du tramak lehenbailehen bidaltzen direla.

Halaber, sareko interfazeko mezuen bidalketa piloa handitu egin dezakegu, eta horrela errendimendua hobetu egingo dugu apur bat, batez ere gigabit motako txarteletan, eta horietan berezko parametroa 1000n dago. Horretarako ifconfig komandoa erabili behar da:

ifconfig eth0 txqueuelen 10000 

Azkenik, egindako beste optimizazio bat TCP Tuning Guide-n adierazitakoa da eta sareko driver batzuetan dagoen bug-ari buruzkoa da (linuxen gunean 2.6.12 bertsioa baino lehenagoko bertsioetan integraturiko driverrak); nukleoan paketeen segmentazioa egiteko deskargari lotuta dago. Horretarako, hauxe egin behar da:

ethtool -K eth0 tso off


Itzuli i2BASQUEen GRID eskuliburura

Tresna pertsonalak
Beste hizkuntzetan