Бул макалада биз сервердин жүгү эмне үчүн көбөйүп жатканын карап чыгабыз жана жогорку жүктөө процесстерин оптималдаштыруунун ар кандай жолдорун талкуулайбыз. Apache/Nginx жана MySQLде кодду оптималдаштырууга өзгөчө көңүл бурулат, биз жардамчы курал катары кэш жөнүндө сүйлөшөбүз, ошондой эле DDOS чабуулдары сыяктуу мүмкүн болуучу тышкы коркунучтарды жана аларды алдын алуу жолдорун карап чыгабыз.
Эмне үчүн Server Load пайда болот
Серверди оптималдаштырууга өтүүдөн мурун, ресурстарга учурдагы жүктөмдү кылдат талдоо керек. Бул процессордун жүгүн, оперативдүү эстутумдун колдонулушун, тармактын активдүүлүгүн жана башка негизги параметрлерди өлчөөнү камтыйт. Динамика жана эң жогорку жүктөмдөрдү түшүнүү кыйынчылыктарды аныктоого жана ресурстарды бөлүштүрүүнү оптималдаштырууга мүмкүндүк берет, ошону менен сервер инфраструктурасынын туруктуулугун жана иштешин жогорулатат.
Сервердин жогорку жүктөлүшүнүн алгачкы көйгөйлөрүн чечүү үчүн, биз жалпы сервер диагностикасын жүргүзүүнү сунуштайбыз. Эгерде бул жетишсиз болсо, ресурстарды кененирээк талдоо зарыл. Кошумча курал катары Linux серверинин журналдарын изилдөө пайдалуу болушу мүмкүн, анткени көпчүлүк учурларда көйгөйдүн булагы ушул жерден табылат.
Apache/Nginx серверин оптималдаштыруу
Индекстөөдөн улам сервердик жүктөм көбөйдү
Сервердеги индекстөөдөн улам жүктөмдүн көбөйүшү, мисалы, издөө системалары сиздин сайтыңыздагы көп сандагы барактарды сканерлегенде пайда болушу мүмкүн. Бул сервердик ресурстардын көбөйүшүнө алып келиши мүмкүн жана натыйжада сайттын иштешин жайлатышы мүмкүн. Себебин аныктоо салыштырмалуу жөнөкөй; сиз даректе жайгашкан файлды ачышыңыз керек:
/var/www/httpd-logs/sitename.access.log
Издөө системалары тарабынан индекстелгенде, колдонуучу төмөнкү мүнөздөгү жазууларды көрөт:
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)"
Жүктү азайтуунун биринчи чечими катары, индекстөөнүн кажети жок баракчаларда "noindex" жана "nofollow" мета тегдерин орнотууну колдонсоңуз болот . Экинчи чечим - бул .htaccess файлы, анда белгилүү бир издөө системаларына тиешелүү жазууларды кошуу керек, мисалы, Yandex жана Google'дан жашыруу үчүн:
SetEnvIfNoCase User-Agent "^Yandex" search_bot
SetEnvIfNoCase User-Agent "^Googlebot" search_bot
Order Allow,Deny
Allow from all
Deny from env=search_bot
Ошо сыяктуу эле, башка издөө системалары үчүн да түзөтүүлөрдү киргизүү керек. Белгилей кетүүчү нерсе, .htaccessтин мүмкүнчүлүктөрү индекстөөнү бөгөттөө менен гана чектелбейт. Анын негизги функциялары менен макалада кененирээк таанышып алууну сунуштайбыз.
Кэштөө орнотууларын колдонуу
Сервердеги туура эмес кэштөө жөндөөлөрү да көп жүктөөгө алып келиши мүмкүн. Бул параметрди оптималдаштыруу үчүн конфигурация файлдарына же .htaccess файлына тиешелүү өзгөртүүлөрдү киргизүү керек . Apache үчүн акыркы вариант артыкчылыктуу, Nginx үчүн биринчиси.
Apache серверинде .htacess файлын ачып, төмөнкү кодду киргизишиңиз керек :
<FilesMatch ".(flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf|doc|docx)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>
Андан кийин, буйрукту колдонуп, " Мөөнөтү бүтөт " модулун иштетиңиз :
sudo a2enmod expires
Андан кийин, веб-серверди өчүрүп күйгүзүңүз:
sudo service apache2 restart
Жана көрсөтүү менен модулду активдештирүү:
ExpiresActive On
Nginx серверинде конфигурация файлына төмөнкү кодду кошуу жетиштүү:
location ~* .(jpg|jpeg|gif|png|ico|css|swf|flv|doc|docx)$ {
root /var/www/yoursite.com;
}
Жана кызматты кайра жүктөө:
sudo service nginx restart
Бул жөндөөлөр менен " Уруксат берүү " жана "Тыюу салуу " директивалары айланып өтөрүн эске алыңыз.
Маалыматтарды кысуу колдонуу
Apache жана Nginx веб-серверлеринде Gzip аркылуу маалыматтарды кысууну иштетүү сервер менен кардар ортосунда берилүүчү маалыматтардын көлөмүн азайтууга жардам берет, бул иштин натыйжалуулугун жакшыртат жана веб-баракчаны жүктөө убактысын кыскартат.
Apache'де Gzip'ти иштетүү үчүн , mod_deflate модулун иштетишиңиз керек :
sudo a2enmod deflate
Андан кийин, веб серверди өчүрүп күйгүзүңүз:
sudo service apache2 restart
Акырында, конфигурация файлына же .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>
Бул конфигурация файлдардын айрым түрлөрү үчүн кысуу мүмкүнчүлүгүн берет жана аны сүрөттөр үчүн өчүрөт.
Nginx учурда , конфигурация конфигурация файлынын http блогунда жүргүзүлөт. Төмөнкү кодду кошуу керек:
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;
Apache сыяктуу эле , бул жерде белгилүү бир файл түрлөрү үчүн кысуу параметрлери орнотулган. Веб-серверлердин кайсынысына болбосун өзгөртүүлөрдү киргизгенден кийин, кызматты кайра жүктөө талап кылынат:
sudo service apache2 restart
Or
sudo service nginx restart
Серверге DDOS чабуулу
Жогорку сервер жүктөө DDoS чабуулунун натыйжасында пайда болушу мүмкүн. DDoS чабуулунун бар экендигин аныктоо трафиктин кескин көбөйүшүнө, анормалдуу суроо-талаптарга жана сервердин иштешинин төмөндөшүнө мониторинг жүргүзүү аркылуу жүргүзүлүшү мүмкүн. Бир IP даректен кайталанган суроо-талаптар үчүн журналдарды карап чыгуу же порт сканерлөө дагы мүмкүн болгон DDoS чабуулун көрсөтөт. Көптөгөн коргоо чаралары бар, бирок биз негизин гана талкуулайбыз.
CDNди (Контент жеткирүү тармагы) колдонуу . CDN веб-сервериңиз менен колдонуучулардын ортосунда ортомчу катары кызмат кыла алат, трафикти бөлүштүрөт жана DDoS чабуулунун таасирин азайтуу үчүн мазмунду кэштейт. CDNдерде жүктү бөлүштүрүү жана трафикти чыпкалоо сыяктуу орнотулган DDoS коргоо механизмдери да болушу мүмкүн.
Брандмауэрлерди жана басып кирүүлөрдү аныктоо системаларын (IDS/IPS) конфигурациялоо . Брандмауэрлерди IP даректери жана порттор сыяктуу ар кандай критерийлердин негизинде трафикти чыпкалоо үчүн конфигурациялоого болот. IDS/IPS трафиктин анормалдуу жүрүм-турумун аныктап, шектүү байланыштарды бөгөттөй алат. Бул куралдар потенциалдуу зыяндуу трафикти көзөмөлдөөдө жана бөгөттөөдө натыйжалуу болушу мүмкүн.
DDoS чабуулдарынын таасирин азайтуу үчүн Apache жана Nginx веб серверлерин конфигурациялоо.
Apache үчүн чечим катары биз mod_evasive модулун иштетебиз. Бул үчүн, httpd.conf же apache2.conf конфигурация файлына төмөнкү сапты комментарийден алып салыңыз же кошуңуз :
LoadModule evasive20_module modules/mod_evasive.so
Ошол эле файлда сиз орнотуулар блогун кошушуңуз керек:
<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>
Ошо сыяктуу эле, биз mod_ratelimit модулун иштетебиз :
LoadModule ratelimit_module modules/mod_ratelimit.so
Жана конфигурацияны кошуңуз:
<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>
Nginx үчүн конфигурация Apacheге окшош . nginx.conf конфигурация файлында төмөнкү директиваларды колдонуу керек:
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;
...
}
}
Кызматтардын ар бирине өзгөртүүлөрдү киргизгенден кийин, аларды кайра жүктөө керек:
sudo systemctl restart apache2
же болбосо:
sudo systemctl restart nginx
Бул мисалдар конкреттүү талаптарга жана чабуулдардын мүнөзүнө жараша андан ары ылайыкталышы мүмкүн болгон негизги конфигурацияны гана камсыз кылат.
MySQL сурамдарын оптималдаштыруу
Веб-серверде MySQL маалымат базасынын суроо-талаптарын оптималдаштыруу ар кандай жолдор менен ишке ашырылышы мүмкүн жана алардын бири конфигурация файлын туура конфигурациялоо болуп саналат. Адатта, бул файл my.cnf же my.ini деп аталат жана /etc/ же /etc/mysql/ каталогунда жайгашкан . Аны ачып, төмөнкү өзгөртүүлөрдү киргизишиңиз керек:
[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
Ошондой эле сервердин маалымат базасы менен өз ара аракеттенүүнү жеңилдете турган кошумча сунуштарды карап көрөлү:
- колдонуу түшүндүр анын аткарылышын талдоо үчүн SQL сурамынын алдында буйрук. Бул суроонун аткарылышынын планын алууга жана кайсы индекстер колдонулганын, кайсы таблицалар сканерленгенин ж.б. аныктоого мүмкүндүк берет.
- Индекстер маалыматтарды издөөнү тездетет, андыктан туура иштелип чыккан индекстер суроонун натыйжалуулугун бир топ жакшыртат. Көбүнчө колдонулган тилкелерге көңүл буруңуз КАЙДА or үгүшүү шарттары.
- Колдонуудан алыс болуңуз ТАНДОО *. Таблицадагы бардык мамычаларды тандоонун ордуна, сурооңуз үчүн чындап керектүү тилкелерди гана көрсөтүңүз.
- ичинде функцияларды колдонуудан качыңыз КАЙДА шарттар. Функцияларды колдонуу (мисалы ТӨМӨН, ЖОГОРКУ, LEFT, УКУГУ) менен КАЙДА шарттар индекстерди жараксыз кылып коюшу мүмкүн. шарттарда аларды түздөн-түз колдонуудан качууга аракет кыл.
- колдонуу ички JOIN мүмкүн болгон жерде, анткени ал, адатта, натыйжалуураак. Ошондой эле, кошулуу үчүн тиешелүү тилкелерде индекстер бар экендигин текшериңиз.
- колдонуу LIMIT Эгер сиз натыйжалардын белгилүү бир санын гана алышыңыз керек болсо, кайтарылган саптардын санын чектөө үчүн.
- Сервердин жүгүн азайтуу үчүн сурамдын натыйжаларын кэштеңиз, айрыкча алар сейрек өзгөрсө.
Почта сервери серверде жогорку жүктү жаратат
Бул бөлүмдө биз почта сервери көп жүктөмгө дуушар болуп жатканын кантип аныктоону жана анын иштешин оптималдаштыруу үчүн кандай кадамдарды жасоого болорун, анын ичинде билдирүүлөр кезегин текшерүүнү жана сервердин параметрлерин конфигурациялоону карап чыгабыз. Билдирүү кезегин текшерүүдөн баштаңыз. mailq утилитасы муну ишке ашырууга жардам бере алат, аны активдештирүү үчүн терминалга тиешелүү буйрукту киргизиңиз:
mailq
Бул, эгерде бар болсо, кезекте турган билдирүүлөрдүн тизмесин көрсөтөт. Ар бир билдирүү өзүнүн уникалдуу идентификатору жана жөнөтүү статусу жөнүндө маалымат менен көрсөтүлөт. Ушундай эле натыйжаны почта кардары журналдарын карап чыгуу менен алууга болот.
Көпчүлүк учурларда, сервер спам жөнөтө баштаганда компромисске учураганда жогорку жүктөм пайда болот. Бирок, текшерүүдөн кийин администратор серверге сырттан чабуул жасалган эмес деп ишенсе жана колдонуучулар спамга көңүл бурбаса, почта серверин оптималдаштырууга өтүүгө убакыт келди. Бул жерде жардам бере турган кадамдар:
- Домениңиздин DNS жазуулары, анын ичинде туура конфигурацияланганын текшериңиз SPF, dkim кеңейтүүсү, жана DMARC кеңейтүүсү почта жеткирүүнү жакшыртуу жана спамдан коргоо үчүн жазуулар. Параметрлердин туура конфигурациясын макаладан тапса болот почта серверинин диагностикасы.
- Блокторду болтурбоо жана почтаны жеткирүүнү тездетүү үчүн тармак жөндөөлөрүн, анын ичинде брандмауэр конфигурациясын жана маршруттук эрежелерин текшериңиз.
- Сервердин жүгүнө жараша билдирүү кезегинин параметрлерин конфигурациялаңыз. Бул кезектин максималдуу өлчөмүн жана күтүү убакыттарын орнотууну камтышы мүмкүн.
- Бул макалада биз мурда талкууланган чечимдерди карап көрөлү. Ишти жакшыртуу үчүн почта серверинин маалымат базасын мезгил-мезгили менен оптималдаштырып туруңуз, DNS сурамдары сыяктуу маалыматтарды издөөнү жана иштетүүнү тездетүү үчүн кэш механизмдерин колдонуңуз.
- Эгер почта сервери дагы эле жогорку жүктөмгө туш болсо, почта серверлеринин кластерин же булут чечимдерин колдонуу сыяктуу масштабдоо параметрлерин карап көрүңүз.
жыйынтыктоо
Сервер жүктөмүнүн көбөйүшү веб-сайттын жүктөө ылдамдыгына түздөн-түз таасирин тийгизип, акырында издөө системаларында колдонуучунун тажрыйбасына жана репутациясына таасирин тийгизет. Ошентип, бул жүктү эффективдүү башкаруу ресурстун үзгүлтүксүз иштешин камсыз кылууда жана анын коноктор үчүн жеткиликтүүлүгүн жогорулатууда негизги ролду ойнойт.