Lleihau llwyth gweinydd

Yn yr erthygl hon, byddwn yn ymchwilio i pam mae llwyth gweinydd cynyddol yn digwydd ac yn trafod gwahanol ffyrdd o wneud y gorau o brosesau llwyth uchel. Rhoddir sylw arbennig i optimeiddio cod yn Apache / Nginx a MySQL, byddwn yn siarad am caching fel offeryn ategol, a hefyd yn ystyried bygythiadau allanol posibl, megis ymosodiadau DDOS, a ffyrdd i'w hatal.

Pam mae Llwyth Gweinydd yn Digwydd

Cyn symud ymlaen i optimeiddio gweinydd, mae angen cynnal dadansoddiad trylwyr o'r llwyth cyfredol ar adnoddau. Mae hyn yn cynnwys mesur llwyth CPU, defnydd RAM, gweithgaredd rhwydwaith, a pharamedrau allweddol eraill. Mae deall deinameg a llwythi brig yn caniatáu nodi tagfeydd a gwneud y gorau o ddyrannu adnoddau, gan gynyddu sefydlogrwydd a pherfformiad seilwaith y gweinydd.

Ar gyfer datrys problemau llwyth uchel ar y gweinydd i ddechrau, rydym yn argymell cynnal diagnosteg gweinydd cyffredinol . Os nad yw hyn yn ddigonol, mae angen dadansoddiad mwy manwl o adnoddau . Fel offeryn ategol, gall archwilio logiau'r gweinydd Linux fod yn ddefnyddiol, gan mai dyma lle mae ffynhonnell y broblem i'w chael yn y rhan fwyaf o achosion.

Optimeiddio Gweinydd Apache / Nginx

Llwyth Gweinydd Cynyddol Oherwydd Mynegeio

Gall llwyth cynyddol oherwydd mynegeio ar y gweinydd ddigwydd, er enghraifft, pan fydd peiriannau chwilio yn sganio nifer fawr o dudalennau ar eich gwefan. Gall hyn arwain at ddefnydd cynyddol o adnoddau gweinydd ac, o ganlyniad, arafu perfformiad y safle. Mae canfod yr achos yn gymharol syml; mae angen ichi agor y ffeil sydd wedi'i lleoli yn:

/var/www/httpd-logs/sitename.access.log

Pan gaiff ei fynegeio gan beiriannau chwilio, bydd y defnyddiwr yn gweld cofnodion o'r natur ganlynol:

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)"

Fel ateb cyntaf i leihau'r llwyth, gallwch ddefnyddio gosodiad y tagiau meta "noindex" a "nofollow" ar dudalennau nad oes angen eu mynegeio. Yr ail ateb yw'r ffeil .htaccess , lle mae angen ychwanegu cofnodion sy'n cyfateb i beiriannau chwilio penodol, er enghraifft, i guddio rhag Yandex a Google:

SetEnvIfNoCase User-Agent "^Yandex" search_bot
SetEnvIfNoCase User-Agent "^Googlebot" search_bot
Order Allow,Deny
Allow from all
Deny from env=search_bot

Yn yr un modd, mae angen gwneud golygiadau ar gyfer peiriannau chwilio eraill. Dylid nodi nad yw galluoedd .htaccess wedi'u cyfyngu i rwystro mynegeio yn unig. Rydym yn argymell ymgyfarwyddo â'i phrif nodweddion yn yr erthygl.

Defnyddio Gosodiadau Caching

Gall gosodiadau storio anghywir ar y gweinydd hefyd arwain at lwyth uchel. I optimeiddio'r paramedr hwn, mae angen gwneud newidiadau cyfatebol yn y ffeiliau ffurfweddu neu .htaccess . Yn achos Apache, yr opsiwn olaf sy'n well, ar gyfer Nginx - y cyntaf.

Ar weinydd Apache , mae angen i chi agor y ffeil .htacess a mewnosod y cod canlynol:

<FilesMatch ".(flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf|doc|docx)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>

Yna, galluogwch y modiwl Expires gan ddefnyddio'r gorchymyn:

sudo a2enmod expires

Ar ôl hynny, ailgychwynwch y gweinydd gwe:

sudo service apache2 restart

Ac actifadu'r modiwl trwy nodi:

ExpiresActive On

Ar weinydd Nginx , mae'n ddigon ychwanegu'r cod canlynol at y ffeil ffurfweddu:

location ~* .(jpg|jpeg|gif|png|ico|css|swf|flv|doc|docx)$ {
root /var/www/yoursite.com;
}

A pherfformiwch ail-lwytho gwasanaeth:

sudo service nginx restart

Sylwch, gyda'r gosodiadau hyn, y bydd y cyfarwyddebau Caniatáu a Gwrthod yn cael eu hosgoi.

Defnyddio Cywasgu Data

Mae galluogi cywasgu data gan ddefnyddio Gzip ar weinyddion gwe Apache ac Nginx yn helpu i leihau faint o ddata sy'n cael ei drosglwyddo rhwng y gweinydd a'r cleient, sy'n gwella perfformiad ac yn lleihau amser llwytho tudalennau gwe.

I alluogi Gzip ar Apache , mae angen i chi actifadu'r modiwl mod_deflate :

sudo a2enmod deflate

Yna, ailgychwynwch y gweinydd gwe:

sudo service apache2 restart

Ac yn olaf, ychwanegwch y bloc canlynol i'r ffeil ffurfweddu neu .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>

Mae'r cyfluniad hwn yn galluogi cywasgu ar gyfer rhai mathau o ffeiliau ac yn ei analluogi ar gyfer delweddau.

Yn achos Nginx , mae ffurfweddu'n digwydd yn y bloc http o'r ffeil ffurfweddu. Mae angen ychwanegu'r cod canlynol:

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;

Yn debyg i Apache , yma mae'r paramedrau cywasgu ar gyfer rhai mathau o ffeiliau wedi'u gosod. Ar ôl gwneud newidiadau i unrhyw un o'r gweinyddion gwe, mae angen ail-lwytho'r gwasanaeth:

sudo service apache2 restart

Or

sudo service nginx restart

Ymosodiad DDOS ar y Gweinydd

Gall llwyth gweinydd uchel ddigwydd o ganlyniad i ymosodiad DDoS. Gellir nodi presenoldeb ymosodiad DDoS trwy fonitro cynnydd sydyn mewn traffig, ceisiadau annormal, a gostyngiadau perfformiad gweinydd. Gall adolygu logiau ar gyfer ceisiadau dro ar ôl tro o un cyfeiriad IP neu sganio porthladd hefyd nodi ymosodiad DDoS posibl. Mae yna lawer o fesurau amddiffyn, ond dim ond y pethau sylfaenol y byddwn yn eu trafod.

Defnyddio CDN (Rhwydwaith Cyflwyno Cynnwys) . Gall CDN wasanaethu fel cyfryngwr rhwng eich gweinydd gwe a defnyddwyr, gan ddosbarthu traffig a storio cynnwys yn y storfa dros dro i liniaru effaith ymosodiad DDoS. Gall CDNs hefyd gynnwys mecanweithiau amddiffyn DDoS adeiledig, gan gynnwys dosbarthu llwyth a hidlo traffig.

Ffurfweddu waliau tân a systemau canfod ymyrraeth (IDS/IPS) . Gellir ffurfweddu waliau tân i hidlo traffig yn seiliedig ar feini prawf amrywiol, megis cyfeiriadau IP a phorthladdoedd. Gall IDS/IPS ganfod ymddygiad traffig annormal a rhwystro cysylltiadau amheus. Gall yr offer hyn fod yn effeithiol wrth olrhain a rhwystro traffig a allai fod yn faleisus.

Ffurfweddu gweinyddwyr gwe Apache a Nginx i liniaru effaith ymosodiadau DDoS.

Fel ateb ar gyfer Apache, rydym yn galluogi'r modiwl mod_evasive . I wneud hyn, dad-sylwadwch neu ychwanegwch y llinell ganlynol yn y ffeil ffurfweddu httpd.conf neu apache2.conf :

LoadModule evasive20_module modules/mod_evasive.so

Yn yr un ffeil, mae angen i chi ychwanegu bloc gosodiadau:

<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>

Yn yr un modd, rydym yn actifadu'r modiwl mod_ratelimit :

LoadModule ratelimit_module modules/mod_ratelimit.so

Ac ychwanegwch y cyfluniad:

<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>

Mae'r ffurfweddiad ar gyfer Nginx yn debyg i Apache . Yn y ffeil ffurfweddu nginx.conf , mae angen defnyddio'r cyfarwyddebau canlynol:

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;

        ...
    }
}

Ar ôl gwneud newidiadau i bob un o'r gwasanaethau, mae angen eu hail-lwytho:

sudo systemctl restart apache2

Neu:

sudo systemctl restart nginx

Mae'r enghreifftiau hyn yn darparu cyfluniad sylfaenol yn unig, y gellir ei addasu ymhellach yn dibynnu ar ofynion penodol a natur ymosodiadau.

Optimeiddio Ymholiadau MySQL

Gellir cyflawni optimeiddio ymholiadau cronfa ddata MySQL ar weinydd gwe mewn amrywiol ffyrdd, ac un ohonynt yw ffurfweddu'r ffeil ffurfweddu'n gywir. Fel arfer, enw'r ffeil hon yw my.cnf neu my.ini ac mae wedi'i lleoli yn y cyfeiriadur /etc/ neu /etc/mysql/ . Mae angen i chi ei agor a gwneud y newidiadau canlynol:

[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

Gadewch i ni hefyd ystyried argymhellion ychwanegol a all hwyluso rhyngweithio â chronfa ddata'r gweinydd:

1. Defnyddiwch y ESBONIAD gorchymyn cyn ymholiad SQL i ddadansoddi ei weithrediad. Mae hyn yn caniatáu ichi gael cynllun gweithredu ar gyfer yr ymholiad a phenderfynu pa fynegeion a ddefnyddir, pa dablau sy'n cael eu sganio, ac ati.
2. Mae mynegeion yn cyflymu'r broses o chwilio am ddata, felly gall mynegeion sydd wedi'u dylunio'n gywir wella perfformiad ymholiad yn sylweddol. Rhowch sylw i golofnau a ddefnyddir yn aml yn LLE or YMUNO amodau.
3. Osgoi defnyddio SELECT *. Nodwch dim ond y colofnau hynny sy'n wirioneddol angenrheidiol ar gyfer eich ymholiad, yn lle dewis pob colofn mewn tabl.
4. Osgoi defnyddio swyddogaethau yn LLE amodau. Defnyddio swyddogaethau (fel LOWER, UCHAF, CHWITH, DDE) yn LLE gall amodau wneud mynegeion yn ddiwerth. Ceisiwch osgoi eu defnyddio'n uniongyrchol mewn amodau.
5. Defnyddio INNER JOIN lle bo modd, gan ei fod fel arfer yn fwy effeithlon. Hefyd, sicrhewch fod gan y colofnau cyfatebol ar gyfer ymuno fynegeion.
6. Defnyddio LIMIT i gyfyngu ar nifer y rhesi a ddychwelir os oes angen i chi gael nifer benodol o ganlyniadau yn unig.
7. Ystyriwch caching canlyniadau ymholiad, yn enwedig os ydynt yn newid yn anaml, i leihau llwyth gweinydd.

Mae'r Gweinyddwr Post yn Creu Llwyth Uchel ar y Gweinydd

Yn yr adran hon, byddwn yn archwilio sut i benderfynu a yw'r gweinydd post yn profi llwyth uchel a pha gamau y gellir eu cymryd i optimeiddio ei weithrediad, gan gynnwys gwirio'r ciw negeseuon a ffurfweddu paramedrau'r gweinydd. Dechreuwch trwy wirio'r ciw negeseuon. Gall y cyfleustodau mailq helpu gyda hyn, i'w actifadu, nodwch y gorchymyn cyfatebol yn y derfynell:

mailq

Bydd hyn yn dangos rhestr o negeseuon yn y ciw, os o gwbl. Bydd pob neges yn cael ei harddangos gyda'i dynodwr unigryw a gwybodaeth am y statws anfon. Gellir cael canlyniad tebyg trwy adolygu'r logiau cleient post.

Yn y rhan fwyaf o achosion, mae llwyth uchel yn digwydd os bydd y gweinydd yn cyfaddawdu pan fydd yn dechrau anfon sbam. Fodd bynnag, ar ôl gwirio bod y gweinyddwr yn hyderus nad yw'r gweinydd wedi cael ei ymosod o'r tu allan ac nad yw defnyddwyr yn esgeuluso sbam, mae'n bryd symud ymlaen i optimeiddio'r gweinydd post. Dyma'r camau a fydd yn helpu:

1. Sicrhewch fod cofnodion DNS eich parth wedi'u ffurfweddu'n gywir, gan gynnwys SPF, DKIM, a DMARC cofnodion i wella dosbarthiad post a diogelu rhag sbam. Mae cyfluniad cywir y paramedrau i'w gweld yn yr erthygl ar diagnosteg gweinydd post.
2. Gwiriwch osodiadau rhwydwaith, gan gynnwys ffurfweddiad wal dân a rheolau llwybro, i osgoi blociau a chyflymu'r broses o ddosbarthu post.
3. Ffurfweddu paramedrau ciw neges yn ôl llwyth y gweinydd. Gall hyn gynnwys gosod uchafswm maint y ciw a seibiannau amser.
4. Ystyriwch yr atebion a drafodwyd gennym yn yr erthygl hon yn gynharach. Optimeiddio cronfa ddata gweinydd post o bryd i'w gilydd i wella perfformiad, defnyddio mecanweithiau caching i gyflymu chwilio a phrosesu data, megis ymholiadau DNS.
5. Os yw'r gweinydd post yn dal i ddod ar draws llwyth uchel yn rheolaidd, ystyriwch opsiynau graddio, megis defnyddio clwstwr o weinyddion post neu ddatrysiadau cwmwl.

Casgliad

Mae cynnydd mewn llwyth gweinydd yn effeithio'n uniongyrchol ar gyflymder llwytho gwefan, gan effeithio yn y pen draw ar brofiad defnyddwyr ac enw da mewn peiriannau chwilio. Felly, mae rheoli'r llwyth hwn yn effeithiol yn chwarae rhan allweddol wrth sicrhau gweithrediad parhaus yr adnodd a chynyddu ei hygyrchedd i ymwelwyr.