Szerver terhelésének csökkentése

Ebben a cikkben megvizsgáljuk, miért fordul elő megnövekedett kiszolgálóterhelés, és megvitatjuk a nagy terhelésű folyamatok optimalizálásának különféle módjait. Külön figyelmet fordítunk az Apache/Nginx és a MySQL kódoptimalizálására, szót ejtünk a gyorsítótárazásról, mint segédeszközről, és figyelembe vesszük a lehetséges külső fenyegetéseket is, mint például a DDOS támadásokat, és ezek megelőzésének módjait.

Miért történik a szerver terhelése?

A szerveroptimalizálás megkezdése előtt alaposan elemezni kell az erőforrások jelenlegi terhelését. Ez magában foglalja a CPU-terhelés, a RAM-használat, a hálózati tevékenység és más kulcsparaméterek mérését. A dinamika és a csúcsterhelések megértése lehetővé teszi a szűk keresztmetszetek azonosítását és az erőforrás-allokáció optimalizálását, ezáltal növelve a szerver-infrastruktúra stabilitását és teljesítményét.

A nagy szerverterhelés kezdeti hibaelhárításához általános szerverdiagnosztika elvégzését javasoljuk. Ha ez nem elegendő, akkor az erőforrások részletesebb elemzése szükséges. Segédeszközként hasznos lehet a Linux szerver naplóinak feltárása, mivel a legtöbb esetben itt található a probléma forrása.

Apache/Nginx szerver optimalizálása

Megnövekedett szerverterhelés az indexelés miatt

A szerver indexelése miatt megnövekedett terhelés fordulhat elő, például amikor a keresőmotorok nagyszámú oldalt vizsgálnak meg az Ön webhelyén. Ez a kiszolgálói erőforrások fokozott igénybevételéhez vezethet, és következésképpen lelassíthatja a webhely teljesítményét. Az ok azonosítása viszonylag egyszerű; meg kell nyitnia a következő helyen található fájlt:

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

A keresőmotorok indexelésekor a felhasználó a következő típusú bejegyzéseket fogja látni:

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

Első megoldásként a terhelés csökkentésére használhatja a "noindex" és a "nofollow" metacímkék beállítását azokon az oldalakon, amelyeket nem kell indexelni. A második megoldás a .htaccess fájl, ahol az adott keresőmotoroknak megfelelő bejegyzéseket kell hozzáadni, például a Yandex és a Google elől való elrejtéshez:

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

Hasonlóképpen, más keresőmotorokhoz is el kell végezni a szerkesztéseket. Meg kell jegyezni, hogy a .htaccess képességei nem korlátozódnak pusztán az indexelés blokkolására. Javasoljuk, hogy a cikkben ismerkedjen meg főbb funkcióival.

A gyorsítótárazási beállítások használata

A szerver helytelen gyorsítótárazási beállításai szintén nagy terheléshez vezethetnek. Ennek a paraméternek az optimalizálásához a konfigurációs fájlokban vagy a .htaccess fájlban kell megfelelő módosításokat végezni . Apache esetén az utóbbi, Nginx esetén az előbbi a jobb választás.

Egy Apache szerveren meg kell nyitnod a .htacess fájlt, és be kell illesztened a következő kódot:

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

Ezután engedélyezze a Lejárat modult a következő paranccsal:

sudo a2enmod expires

Ezután indítsa újra a webszervert:

sudo service apache2 restart

És aktiválja a modult a következő megadásával:

ExpiresActive On

Nginx szerveren elegendő a következő kódot hozzáadni a konfigurációs fájlhoz:

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

És hajtsa végre a szolgáltatás újratöltését:

sudo service nginx restart

Vegye figyelembe, hogy ezekkel a beállításokkal az Allow és Deny direktívák kimaradnak.

Adattömörítés használata

Az Apache és Nginx webszervereken a Gzip használatával történő adattömörítés engedélyezése segít csökkenteni a szerver és a kliens között átvitt adatmennyiséget, ami javítja a teljesítményt és csökkenti a weboldalak betöltési idejét.

A Gzip engedélyezéséhez az Apache- on aktiválni kell a mod_deflate modult:

sudo a2enmod deflate

Ezután indítsa újra a webszervert:

sudo service apache2 restart

Végül adja hozzá a következő blokkot a konfigurációs fájlhoz vagy a .htaccess fájlhoz:

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

Ez a konfiguráció lehetővé teszi a tömörítést bizonyos típusú fájloknál, és letiltja a képeknél.

Nginx esetén a konfiguráció a konfigurációs fájl http blokkjában történik . A következő kódot kell hozzáadni:

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;

Az Apache- hoz hasonlóan itt is bizonyos fájltípusok tömörítési paraméterei vannak beállítva. Bármelyik webszerveren módosítások elvégzése után a szolgáltatás újratöltése szükséges:

sudo service apache2 restart

Or

sudo service nginx restart

DDOS támadás a szerveren

A DDoS támadások következtében magas szerverterhelés léphet fel. A DDoS támadások jelenlétét a forgalom hirtelen növekedésének, a rendellenes kéréseknek és a szerverteljesítmény-csökkenésnek a figyelésével lehet azonosítani. Az egy IP-címről érkező ismételt kérések naplóinak áttekintése vagy a portellenőrzés szintén jelezhet egy lehetséges DDoS-támadást. Számos védelmi intézkedés létezik, de mi csak az alapokat tárgyaljuk.

CDN (tartalomszolgáltató hálózat) használata . A CDN közvetítőként szolgálhat a webszerver és a felhasználók között, elosztva a forgalmat és gyorsítótárazza a tartalmat a DDoS-támadások hatásának enyhítése érdekében. A CDN-ek beépített DDoS-védelmi mechanizmusokkal is rendelkezhetnek, beleértve a terheléselosztást és a forgalomszűrést.

Tűzfalak és behatolásérzékelő rendszerek (IDS/IPS) konfigurálása . A tűzfalak konfigurálhatók úgy, hogy a forgalmat különféle kritériumok, például IP-címek és portok alapján szűrjék. Az IDS/IPS képes észlelni a rendellenes forgalmi viselkedést és blokkolni a gyanús kapcsolatokat. Ezek az eszközök hatékonyak lehetnek a potenciálisan rosszindulatú forgalom nyomon követésében és blokkolásában.

Az Apache és Nginx webszerverek konfigurálása a DDoS támadások hatásának mérséklése érdekében.

Megoldásként az Apache számára engedélyezzük a mod_evasive modult. Ehhez vegyük ki a megjegyzést, vagy adjuk hozzá a következő sort a httpd.conf vagy az apache2.conf konfigurációs fájlhoz:

LoadModule evasive20_module modules/mod_evasive.so

Ugyanabban a fájlban hozzá kell adni egy beállítási blokkot:

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

Hasonlóképpen aktiváljuk a mod_ratelimit modult:

LoadModule ratelimit_module modules/mod_ratelimit.so

És add hozzá a konfigurációt:

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

Az Nginx konfigurációja hasonló az Apache- éhoz . Az nginx.conf konfigurációs fájlban a következő direktívákat kell használni:

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;

        ...
    }
}

Az egyes szolgáltatások módosítása után azokat újra be kell tölteni:

sudo systemctl restart apache2

Vagy:

sudo systemctl restart nginx

Ezek a példák csak egy alapkonfigurációt adnak, amely a konkrét követelményektől és a támadások természetétől függően tovább módosítható.

MySQL lekérdezések optimalizálása

A MySQL adatbázis-lekérdezések optimalizálása egy webszerveren többféleképpen is megvalósítható, ezek egyike a konfigurációs fájl megfelelő konfigurálása. Ez a fájl jellemzően my.cnf vagy my.ini nevű, és az /etc/ vagy /etc/mysql/ könyvtárban található . Meg kell nyitni, és a következő módosításokat kell végrehajtani:

[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

Tekintsünk további ajánlásokat is, amelyek megkönnyíthetik a kiszolgáló adatbázissal való interakciót:

1. Használja a Magyarázza parancsot egy SQL-lekérdezés előtt a végrehajtás elemzéséhez. Ez lehetővé teszi, hogy egy végrehajtási tervet kapjon a lekérdezéshez, és meghatározza, hogy mely indexeket használja, mely táblákat vizsgálja meg stb.
2. Az indexek felgyorsítják az adatkeresést, így a megfelelően megtervezett indexek jelentősen javíthatják a lekérdezés teljesítményét. Ügyeljen a gyakran használt oszlopokra AHOL or JOIN körülmények.
3. Kerülje a használatát SELECT *. Csak azokat az oszlopokat adja meg, amelyek valóban szükségesek a lekérdezéshez, ahelyett, hogy a táblázat összes oszlopát kijelölné.
4. Kerülje a funkciók használatát AHOL körülmények. Funkciók használata (pl ALSÓ, FELSŐ, LEFT, RIGHT) ben AHOL feltételek használhatatlanná tehetik az indexeket. Kerülje a közvetlen felhasználásukat olyan körülmények között.
5. Felhasználás INNER JOIN ahol lehetséges, mivel általában hatékonyabb. Győződjön meg arról is, hogy az összekapcsoláshoz megfelelő oszlopok rendelkeznek indexekkel.
6. Felhasználás LIMIT a visszaadott sorok számának korlátozása, ha csak bizonyos számú eredményt kell elérnie.
7. Fontolja meg a lekérdezések eredményeinek gyorsítótárazását, különösen, ha ritkán változnak, a szerverterhelés csökkentése érdekében.

A levelezőszerver nagy terhelést hoz létre a szerveren

Ebben a szakaszban azt vizsgáljuk meg, hogyan állapítható meg, hogy a levelezőszerver nagy terhelés alatt áll-e, és milyen lépéseket lehet tenni a működésének optimalizálása érdekében, beleértve az üzenetsor ellenőrzését és a szerver paramétereinek konfigurálását. Kezdjük az üzenetsor ellenőrzésével. A mailq segédprogram segíthet ebben, aktiválásához írjuk be a megfelelő parancsot a terminálba:

mailq

Ez megjeleníti a sorban lévő üzenetek listáját, ha vannak ilyenek. Minden üzenet egyedi azonosítójával és a küldés állapotával kapcsolatos információkkal jelenik meg. Hasonló eredmény érhető el a levelezőkliens naplóinak áttekintésével.

A legtöbb esetben nagy terhelés lép fel, ha a szerver kompromittálódik, amikor elkezdi a levélszemét küldését. Ha azonban az ellenőrzés után az adminisztrátor biztos abban, hogy a szervert nem támadták meg kívülről, és a felhasználók nem hanyagolják el a levélszemétet, akkor ideje továbblépni a levelezőszerver optimalizálására. Íme a lépések, amelyek segítenek:

1. Győződjön meg arról, hogy a domain DNS-rekordjai megfelelően vannak konfigurálva, beleértve a következőket: SPF, dkim kiterjesztéstés DMARC kiterjesztés rekordokat a levelek kézbesítésének javítása és a spam elleni védelem érdekében. A paraméterek helyes konfigurációját a következő cikkben találja meg levelezőszerver diagnosztika.
2. Ellenőrizze a hálózati beállításokat, beleértve a tűzfal konfigurációját és az útválasztási szabályokat, hogy elkerülje a blokkolásokat és felgyorsítsa a levelek kézbesítését.
3. Konfigurálja az üzenetsor paramétereit a szerver terhelésének megfelelően. Ez magában foglalhatja a maximális sorméret és az időtúllépések beállítását.
4. Fontolja meg a cikkben korábban tárgyalt megoldásokat. Rendszeresen optimalizálja a levelezőszerver adatbázisát a teljesítmény javítása érdekében, használjon gyorsítótárazási mechanizmusokat az adatkeresés és -feldolgozás felgyorsítására, például a DNS-lekérdezéseket.
5. Ha a levelezőszerver továbbra is rendszeresen nagy terhelésbe ütközik, fontolja meg a skálázási lehetőségeket, például levelezőszerver-fürt vagy felhőmegoldások használatát.

Összegzés

A megnövekedett szerverterhelés közvetlenül befolyásolja a webhelyek betöltési sebességét, végső soron a felhasználói élményt és a keresőmotorok hírnevét. Így ennek a terhelésnek a hatékony kezelése kulcsszerepet játszik az erőforrás folyamatos működőképességének biztosításában és a látogatók számára elérhetőségének növelésében.