Ключови фактори за намиране на затруднено място в ресурсите при претоварване на сървъра на Linux

By | ноември 4, 2021

Много често, въпреки достъпния хардуер, има проблеми с натоварването на сървъра. Може да има редица причини за голямо натоварване на сървъра, като неадекватна RAM/CPU, по-бавни твърди дискове или просто неоптимизиран софтуер. Тази статия ще ви помогне да определите какво е тесното място и къде да инвестирате. Моля, не го приемайте като заместител на професионален съвет/услуга. Винаги трябва да търсите професионална услуга, ако можете да си позволите свързаните с това разходи.

I) Първо, наистина ли имате проблеми?

Обикновено хората търсят натоварване на контролните панели, като използват командата „uptime“ или „top“. Вероятно можете да изпълните командата „uptime“ на вашия root шел, за да разберете какво е натоварването, но бих искал засега да използвате „top“ (моля). Това ще ви помогне да определите колко процесора се отчитат *. Трябва да можете да видите нещо като cpu00, cpu01 и т.н.

Натоварването от ~ 1 за всеки процесор е разумно. Например, вие сте добре, ако натоварването е 3,50 и имате 4 CPU.

Друго нещо, което трябва да имате предвид, докато разглеждате натоварването през времето за активност или отгоре, е да разберете какво показва. Например: (на 2HT CPU сървър, обозначен като 4)

18:30:55 до 17 дни, 5:17, 2 потребители, средно качване: 4,76, 2,97, 2,62

Първата част (3.76) показва средното натоварване за последните 5 минути, докато втората (2.97) и третата (2.62) показват средни стойности съответно от 10 и 15 минути. Вероятно тук е връх, за който не бих се притеснявал твърде много (малко безгрижен?), Но ако сте, продължете да четете!

Доволни ли сте от това как успяхте да идентифицирате, че вашият сървър всъщност е претоварен? Съжалявам, но никога не се знае, защото понякога сървърите са в състояние да се справят с много повече натоварване, отколкото е показано. Средните стойности на натоварването не са толкова точни и може да не винаги са крайният решаващ фактор. Объркан? Това беше просто техническа информация, която не трябва да ви притеснява толкова. Продължавайте, ако натоварванията ви трябва да бъдат притеснени.

* обърнете внимание на използването на термина „докладван“. Използвах този термин, защото P4 CPU с HT технология ще бъде отчетен като 2, дори ако знаете, че вашият сървър има CPU.

II) Къде е проблемът?

За да идентифицирате проблема, трябва да изпълните серия от логически тестове (добре, не е толкова страшно, колкото звучи). Всичко, от което се нуждаете, е малко свободно време, вероятно 30-45 минути, и root достъп до вашия сървър (не очаквайте магия;)). Готови ли сте да започнете? Ето ни!

Забележка: Направете проверките няколко пъти, за да стигнете до добро заключение.

1. Проверете RAM (най-често срещаното затруднение!).

# безплатно -m

Резултатът трябва да изглежда така:

# безплатно -m

общи безплатни споделени буфери, използвани в кеша

Мем: 1963 1912 50 0 28 906

– / + буфери / скрити: 978 985

Промени: 1027 157 869

Някаква реакция от рода на: „О, Боже, почти цялата RAM памет е изтекла.“? Не се страхувайте. Проверете буферите / кеша, който казва, че mb от „985“ RAM все още е свободен в буферите. Докато имате достатъчно памет в буферите и вашият сървър не използва много суап, вие сте доста добри с RAM. Вашият сървър започва да използва SWAP (като Pagefile), който е част от вашия диск, разпределен като памет, но е сравнително много бавен и може да забави системата ви още повече, ако имате зает твърд диск (което се съмнявам, че ще го направите). би направил, ако използвате толкова много RAM). Накратко, най-малко 175 MB налични в буфери и не повече от 200 MB обмен.

Ако проблемът е RAM, вероятно трябва да разгледате оптимизации за вашите PHP / Perl скриптове, заявки + MySQL сървър и Apache.

2. Проверете дали използването на I/O (вход/изход) е прекомерно

Ако има твърде много заявки за четене/запис на един твърд диск, той ще бъде бавен и ще трябва да го надстроите до по-бързо устройство (с повече RPM и кеш). Алтернативата на едно по-бързо устройство е да се раздели натоварването на множество устройства чрез разпространение на по-голямата част от съдържанието на заявката на множество устройства, което може лесно да се постигне чрез „символични връзки“ (меки връзки към файлове/папки). За да определите дали вашият I/O проблем забавя вашия сървър:

# висшестоящ

Прочетете изхода в секцията „iowait“ за всеки процесор. В идеални ситуации трябва да бъде близо до 0%. Въпреки това, ако проверявате по време на пик на натоварване, помислете за повторна проверка на тези стойности няколко пъти, за да стигнете до добро заключение. Всичко над 15% е тревожно. След това можете да проверите скоростта на вашия твърд диск, за да видите дали наистина изостава:

Ако знаете, че вашият твърд диск съществува в / dev / sda или / dev / hda, направете следното. Или изпълнете командата „df -h“, за да проверите на кое устройство се намират вашите данни.

# hdparm -Tt / dev / sda

Изходът:

/ dev / sda:

Времето за кеш четене: 1484 MB за 2,01 секунди = 739,00 MB/s

Дискът чете с буфер: 62 MB за 3,00 секунди = 20,66 MB/s

Беше невероятно да четете кеш буфери, вероятно поради вградения дисков кеш, но показанията на буферния диск са само 20,66 MB / сек. Всичко под 25 MB е нещо, за което трябва да се притеснявате.

3. Консумирана ли е цялата мощност на процесора?

# висшестоящ

Проверете горния изход, за да разберете дали използвате твърде много мощност на процесора. Трябва да потърсите стойността на празен ход в допълнение към всеки вход на процесора. Всичко под 45% е нещо, за което трябва да се притеснявате.

III) Установен проблем, какво е решението?

За да завърша, позволете ми да предложа някои решения за всеки проблем:

Глобално решение на всички проблеми е да се оптимизира MySQL и уеб сървъра, включително PHP / Perl скриптове и заявки. Или най-малкото, което можете да направите, е да оптимизирате настройките на Apache и MySQL сървъра, за да работят по-добре.

1. Твърде много използване на процесора

В „ps -auxf“ или „top“ потърсете процеси, които използват твърде много CPU. Ако е HTTP или MySQL, по-добре оптимизирайте вашите скриптове и заявки, ако е възможно. В повечето случаи е изключително трудно да се оптимизират всички скриптове и заявки и по-добрият вариант е просто да се направи промяна/надграждане на процесора. Двойният процесор би трябвало да работи по-добре, но видът на надстройка, който търсите, зависи от текущия ви процесор.

2. RAM паметта е изчерпана

Сякаш сте в същата ситуация като процесора. Оптимизиране на HTTP, MySQL, скриптове и др. или извършете надграждане на RAM. Можете да инсталирате софтуер за кеширане на Opcode като APC (от Pear) за PHP, за да го накарате да работи по-добре, като същевременно намали натоварването.

3. Дискът е изцяло използван (е, нямам предвид място)

Тук трябва да изберете по-бързо устройство като SATA над нормален IDE или SCSI над SATA. Е, просто говорех по принцип. Трябва да вземете предвид фактори като RPM и кеш, за да направите надграждане, което си заслужава. Вторият вариант е да се получат няколко единици от един и същи клас и да се разпредели натоварването между единиците. Често срещана методология е да се обслужва MySQL от второ устройство.

IV) Заключение

Това не беше ли много полезно? Статията ми може да е дефектна, ааа, извинете. Това е първата ми статия и това нещо наистина погълна доста от мозъчните ми клетки. Това е малко лично, нали? Да се ​​върнем на бизнеса.

При вас в примера проблемът беше с използването на I/O и забавянето на твърдия диск.

Ръководството никога не може да бъде пълно само по себе си или да ви предложи всичко необходимо, за да достигнете експертно ниво (трябва да продължите да се учите, за да достигнете това ниво). Ако се съмнявате, наемете експерти, които да прегледат вашия сървър. Някак си, ако нямате пари за харчене, все още сте в безопасност! Можете да отидете в нашия раздел за помощ за оптимизиране на сървъра за помощ с оптимизирането на вашия сървър.

Вашият коментар

Вашият имейл адрес няма да бъде публикуван. Задължителните полета са отбелязани с *