Í þessari grein munum við kafa ofan í hvers vegna aukið álag á netþjóna á sér stað og ræða ýmsar leiðir til að hámarka ferla með mikið álag. Sérstaklega verður hugað að hagræðingu kóða í Apache/Nginx og MySQL, við munum tala um skyndiminni sem aukaverkfæri og einnig skoða hugsanlegar utanaðkomandi ógnir, eins og DDOS árásir, og leiðir til að koma í veg fyrir þær.
Hvers vegna álag á netþjón á sér stað
Áður en haldið er áfram í hagræðingu netþjónsins er nauðsynlegt að gera ítarlega greiningu á núverandi álagi á auðlindir. Þetta felur í sér að mæla CPU álag, vinnsluminni notkun, netvirkni og aðrar lykilbreytur. Skilningur á gangverki og hámarksálagi gerir kleift að bera kennsl á flöskuhálsa og hámarka úthlutun auðlinda og auka þannig stöðugleika og afköst innviða netþjónsins.
Fyrir fyrstu bilanaleit á miklu álagi á netþjóni mælum við með að framkvæma a almenn greining á netþjónum. Ef þetta er ófullnægjandi, nánar greiningu á auðlindum er nauðsynlegt. Sem hjálpartæki, að kanna logs af Linux þjónn getur verið gagnlegt, þar sem þetta er þar sem uppspretta vandamálsins er að finna í flestum tilfellum.
Hagræðing Apache/Nginx netþjóns
Aukið álag á netþjóni vegna flokkunar
Aukið álag vegna flokkunar á netþjóninum getur átt sér stað, til dæmis þegar leitarvélar skanna fjölda síðna á síðunni þinni. Þetta getur leitt til aukinnar notkunar á auðlindum netþjóna og þar af leiðandi hægt á afköstum síðunnar. Að bera kennsl á orsökina er tiltölulega einfalt; þú þarft að opna skrána sem staðsett er á:
/var/www/httpd-logs/sitename.access.log
Þegar hann er skráður af leitarvélum mun notandinn sjá færslur af eftirfarandi toga:
11.22.33.44 - - [Date and Time] "GET /your-page-path HTTP/1.1" 200 1234 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Sem fyrsta lausn til að draga úr álaginu geturðu notað stillingar meta tags "noindex" og "nofollow" á síðum sem ekki þarf að skrá. Önnur lausnin er . Htaccess skrá, þar sem bæta þarf við færslum sem samsvara tilteknum leitarvélum, til dæmis til að fela sig fyrir Yandex og Google:
SetEnvIfNoCase User-Agent "^Yandex" search_bot SetEnvIfNoCase User-Agent "^Googlebot" search_bot Order Allow,Deny Allow from all Deny from env=search_bot
Á sama hátt þarf að gera breytingar fyrir aðrar leitarvélar. Það skal tekið fram að möguleiki .htaccess takmarkast ekki við að loka á flokkun. Við mælum með því að kynna þér helstu eiginleika þess betur í grein.
Að nota skyndiminnistillingar
Rangar skyndiminnistillingar á þjóninum geta einnig leitt til mikils álags. Til að fínstilla þessa færibreytu þarf að gera samsvarandi breytingar í stillingarskrám eða . Htaccess. Þegar um Apache er að ræða er síðari kosturinn æskilegur, fyrir Nginx - sá fyrrnefndi.
Á Apache þjónn, þú þarft að opna .htacess skrá og settu inn eftirfarandi kóða:
<FilesMatch ".(flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf|doc|docx)$"> Header set Cache-Control "max-age=2592000" </FilesMatch>
Virkjaðu síðan Rennur út mát með því að nota skipunina:
sudo a2enmod expires
Eftir það skaltu endurræsa vefþjóninn:
sudo service apache2 restart
Og virkjaðu eininguna með því að tilgreina:
ExpiresActive On
Á a Nginx miðlara, það er nóg að bæta eftirfarandi kóða við stillingarskrána:
location ~* .(jpg|jpeg|gif|png|ico|css|swf|flv|doc|docx)$ { root /var/www/yoursite.com; }
Og framkvæma endurhleðslu þjónustu:
sudo service nginx restart
Athugaðu að með þessum stillingum er Leyfa og Neita farið framhjá tilskipunum.
Notkun gagnaþjöppunar
Virkja gagnaþjöppun með því að nota Gzip á Apache og Nginx vefþjónum hjálpar til við að draga úr magni gagna sem send er á milli þjónsins og biðlarans, sem bætir afköst og dregur úr hleðslutíma vefsíðu.
Til að gera kleift Gzip on Apache, þú þarft að virkja mod_deflate mát:
sudo a2enmod deflate
Endurræstu síðan vefþjóninn:
sudo service apache2 restart
Og að lokum skaltu bæta eftirfarandi blokk við stillingarskrána eða .htaccess:
<IfModule mod_deflate.c> # Configure compression for specified file types AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/x-javascript application/json # If the browser matches the specified pattern, apply compression only to text/html files BrowserMatch ^Mozilla/4 gzip-only-text/html # If the browser matches the specified version patterns of Mozilla 4.0.6, 4.0.7, 4.0.8, disable compression BrowserMatch ^Mozilla/4\.0[678] no-gzip # If the browser is MSIE (Internet Explorer), disable compression for all files except text/html BrowserMatch \bMSIE !no-gzip !gzip-only-text/html # If the request contains the specified pattern (extensions of image files), disable compression SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip </IfModule>
Þessi uppsetning gerir þjöppun kleift fyrir ákveðnar tegundir skráa og gerir hana óvirka fyrir myndir.
Þegar um er að ræða Nginx, uppsetning á sér stað í HTTP blokk af stillingarskránni. Eftirfarandi kóða þarf að bæta við:
gzip on; gzip_disable "msie6"; # Adds the Vary header, indicating that the response may change depending on the Accept-Encoding header value gzip_vary on; # Enables compression for any proxy servers gzip_proxied any; # Sets the compression level. A value of 6 provides a good balance between compression efficiency and resource use gzip_comp_level 6; # Sets the size of the buffer for compressed data (16 buffers of 8 kilobytes each) gzip_buffers 16 8k; # Specifies that data compression should be used only for HTTP version 1.1 and higher gzip_http_version 1.1; # Sets the file types that can be compressed gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
Líkur á Apache, hér eru þjöppunarfæribreytur fyrir ákveðnar tegundir skráa stilltar. Eftir að hafa gert breytingar á einhverjum af vefþjónunum er þörf á endurhleðslu þjónustu:
sudo service apache2 restart
Or
sudo service nginx restart
DDOS árás á netþjóninn
Mikið álag á netþjóni getur orðið vegna DDoS árásar. Að bera kennsl á tilvist DDoS árásar er hægt að gera með því að fylgjast með skyndilegri aukningu á umferð, óeðlilegum beiðnum og afköstum miðlara. Skoðun á annálum fyrir endurteknar beiðnir frá einni IP-tölu eða gáttarskönnun getur einnig bent til mögulegrar DDoS árásar. Það eru margar verndarráðstafanir en við ræðum aðeins grunnatriðin.
Notkun CDN (Content Delivery Network). CDN getur þjónað sem milliliður milli vefþjónsins þíns og notenda, dreift umferð og skyndiminni til að draga úr áhrifum DDoS árásar. CDN geta einnig haft innbyggða DDoS verndarkerfi, þar á meðal álagsdreifingu og umferðarsíun.
Stilla eldveggi og innbrotsskynjunarkerfi (IDS/IPS). Hægt er að stilla eldveggi til að sía umferð út frá ýmsum forsendum, svo sem IP tölum og höfnum. IDS/IPS getur greint óeðlilega umferðarhegðun og hindrað grunsamlegar tengingar. Þessi verkfæri geta verið áhrifarík við að fylgjast með og hindra hugsanlega skaðlega umferð.
Að stilla Apache og Nginx vefþjóna til að draga úr áhrifum DDoS árása.
Sem lausn fyrir Apache virkjum við mod_evasive mát. Til að gera þetta skaltu afskrifa eða bæta við eftirfarandi línu í httpd.conf or apache2.conf stillingarskrá:
LoadModule evasive20_module modules/mod_evasive.so
Í sömu skrá þarftu að bæta við stillingablokk:
<IfModule mod_evasive20.c> # Hash table size for storing request information DOSHashTableSize 3097 # Number of requests to one page before activating protection DOSPageCount 2 DOSPageInterval 1 # Number of requests to all pages before activating protection DOSSiteCount 50 DOSSiteInterval 1 # Blocking period in seconds for IP addresses DOSBlockingPeriod 10 </IfModule>
Á sama hátt virkjum við mod_ratelimit mát:
LoadModule ratelimit_module modules/mod_ratelimit.so
Og bættu við stillingunni:
<IfModule mod_ratelimit.c> # Setting the output filter for rate limiting (Rate Limit) SetOutputFilter RATE_LIMIT # Beginning of the settings block for the location "/login" <Location "/login"> # Setting the environment variable rate-limit with a value of 1 SetEnv rate-limit 1 # Ending of the settings block for the location "/login" </Location> </IfModule>
Stillingin fyrir Nginx er svipað Apache. Í nginx.conf stillingarskrá þarf að nota eftirfarandi tilskipanir:
http { ... # Defining a zone for connection limits limit_conn_zone $binary_remote_addr zone=addr:10m; # Defining a zone for request limits limit_req_zone $binary_remote_addr zone=req_zone:10m rate=1r/s; server { ... # Configuring connection limits limit_conn addr 10; # Configuring request limits limit_req zone=req_zone burst=5; ... } }
Eftir að hafa gert breytingar á hverri þjónustu þarf að endurhlaða þær:
sudo systemctl restart apache2
Eða:
sudo systemctl restart nginx
Þessi dæmi veita aðeins grunnstillingar, sem hægt er að aðlaga frekar eftir sérstökum kröfum og eðli árása.
Fínstilling á MySQL fyrirspurnum
Hagræðing MySQL gagnagrunnsfyrirspurna á vefþjóni er hægt að ná á ýmsa vegu, og einn af þeim er rétt stillingar á stillingarskránni. Venjulega er þessi skrá nefnd mitt.cnf or my.ini og er staðsett í / etc / or /etc/mysql/ skrá. Þú þarft að opna það og gera eftirfarandi breytingar:
[mysqld] # Location of the file for recording slow queries. Be sure to replace it with your path log-slow-queries = /var/log/mariadb/slow_queries.log # Threshold time for considering slow queries (in seconds) long_query_time = 5 # Enabling recording of queries that do not use indexes log-queries-not-using-indexes = 1 # Disabling query caching query_cache_size = 0 query_cache_type = 0 query_cache_limit = 1M # Size of temporary tables tmp_table_size = 16M max_heap_table_size = 16M # Size of the thread cache thread_cache_size = 16 # Disabling name resolving skip-name-resolve = 1 # Size of the InnoDB buffer pool. Set to 50-70% of available RAM innodb_buffer_pool_size = 800M # Size of the InnoDB log file innodb_log_file_size = 200M
Við skulum líka íhuga viðbótarráðleggingar sem geta auðveldað samskipti við gagnagrunn netþjónsins:
- Notaðu Útskýrðu skipun á undan SQL fyrirspurn til að greina framkvæmd hennar. Þetta gerir þér kleift að fá framkvæmdaráætlun fyrir fyrirspurnina og ákvarða hvaða vísitölur eru notaðar, hvaða töflur eru skannaðar o.s.frv.
- Vísitölur flýta fyrir gagnaleit, svo rétt hönnuð vísitölur geta bætt árangur fyrirspurna verulega. Gefðu gaum að dálkum sem eru oft notaðir í HVAR or JOIN skilyrði.
- Forðastu að nota VELJA *. Tilgreindu aðeins þá dálka sem eru sannarlega nauðsynlegir fyrir fyrirspurn þína, í stað þess að velja alla dálka í töflu.
- Forðastu að nota aðgerðir í HVAR skilyrði. Að nota aðgerðir (svo sem LÆGRI, Uppi, LEFT, RIGHT) í HVAR aðstæður geta gert vísitölur gagnslausar. Reyndu að forðast beina notkun þeirra við aðstæður.
- Nota INNER JOIN þar sem það er hægt, þar sem það er yfirleitt hagkvæmara. Gakktu úr skugga um að samsvarandi dálkar fyrir sameiningu hafi vísitölur.
- Nota LIMIT til að takmarka fjölda skilaðra lína ef þú þarft aðeins að fá ákveðinn fjölda niðurstaðna.
- Íhugaðu að vista niðurstöður fyrirspurna í skyndiminni, sérstaklega ef þær breytast sjaldan, til að draga úr álagi á netþjóni.
Póstþjónninn skapar mikið álag á netþjóninn
Í þessum hluta munum við kanna hvernig á að ákvarða að póstþjónninn sé fyrir miklu álagi og hvaða skref er hægt að gera til að hámarka rekstur hans, þar á meðal að athuga skilaboðaröðina og stilla breytur miðlara. Byrjaðu á því að athuga skilaboðaröðina. The mailq tól getur hjálpað til við þetta, til að virkja það skaltu slá inn samsvarandi skipun í flugstöðinni:
mailq
Þetta mun birta lista yfir skilaboð í biðröðinni, ef einhver er. Hvert skeyti mun birtast með sínu einstaka auðkenni og upplýsingum um sendingarstöðu. Svipaða niðurstöðu er hægt að fá með því að skoða póstbiðlaraskrárnar.
Í flestum tilfellum verður mikið álag ef miðlari er í hættu þegar hann byrjar að senda ruslpóst. Hins vegar, ef kerfisstjórinn er viss um að ekki hafi verið ráðist á þjóninn utan frá og notendur vanræki ruslpóst eftir að hafa athugað, þá er kominn tími til að halda áfram að fínstilla póstþjóninn. Hér eru skrefin sem munu hjálpa:
- Gakktu úr skugga um að DNS færslur lénsins þíns séu rétt stilltar, þar á meðal SPF, dkim framlengingog DMARC viðbót skrár til að bæta póstsendingu og vernda gegn ruslpósti. Réttar stillingar færibreytna er að finna í greininni um greiningu póstþjóns.
- Athugaðu netstillingar, þar á meðal uppsetningu eldveggs og leiðarreglur, til að forðast blokkir og flýta fyrir afhendingu pósts.
- Stilltu færibreytur fyrir skilaboðaröð í samræmi við álag á netþjóni. Þetta getur falið í sér að stilla hámarksstærð biðraðar og tímamörk.
- Skoðaðu lausnirnar sem við ræddum í þessari grein áðan. Fínstilltu reglulega gagnagrunn póstþjónsins til að bæta árangur, notaðu skyndiminni til að flýta fyrir gagnaleit og vinnslu, svo sem DNS fyrirspurnum.
- Ef póstþjónninn lendir enn reglulega í miklu álagi skaltu íhuga stærðarmöguleika, svo sem að nota þyrping af póstþjónum eða skýjalausnir.
Niðurstaða
Aukið álag á netþjóni hefur bein áhrif á hleðsluhraða vefsíðna og hefur að lokum áhrif á upplifun notenda og orðspor í leitarvélum. Þannig gegnir áhrifarík stjórnun á þessu álagi lykilhlutverki við að tryggja stöðuga virkni auðlindarinnar og auka aðgengi hennar fyrir gesti.