Freesco, NND, CDN, EOS

Powiedzcie mi, że się mylę, ale jakoś mam dziwne wrażenie, że admini sobie zagladają na te ładne kolorowe stronki z mrtg i się ekscytują wykresikami, które często nijak się mają do rzeczywistego stanu serwera.
Nie jestem raczej fachowcem od sprzętu, więc nie chcę się wymądrzać, jednak ja bym przyjął w razie podejrzeń następującą kolejność działań.
1. Wyeliminowałbym wszelkie możliwe sprzętowe oszczędzanie energii oraz acpi - na serwrze to nie ma racji bytu.
2. Wpisałbym sobie do crona zapisywanie polecenia uptime do pliku co 15 minut. Po dobie bym przeanalizował i ręcznie namalował sobie wykres. Uptime podaje 3 wartości load average - za ostatnią minutę, ostatnie 5 i ostatnie 15 minut. Prawidłowy wykres powinien mieć tę ostatnią wartość najniższą. Jeśli przeciętne obciążenie 15-minutowe jest wysokie, to wtedy zacząłbym się zastanawiać, co tak bardzo system obciąża.
3. Z doświadczenia wiem, że bardzo często przyczyną wzrostu obciążenia serwera jest niceshaper. Dzieje się tak, jeśli np. serwer jest na neostradzie. Dzieje się tez tak po przeładowaniu iptables i nieprzeładowaniu równocześnie niceshapera. Sprawdziłbym działające usługi. Podejrzane czasowo bym wyłączał. Sprawdził w jakim okresie od startu systemu się to zaczyna. Sprawdziłbym skrypty wpisane do crona, czy czasem to one nie powodują jakichś problemów - szczególnie jeśli obciążenie zwiększa się po północy lub po pełnej godzinie.
Same rysuneczki to można mieć dla userów, żeby się pochwalić jaki admin jest fachura, ale do analizy stanu systemu to się mało nadaje.

_________________
Belfer.one.PL
Audio Cafe

[OT]
Uspokój sie, przecież nie pisałem do Ciebie. Jakbyś TY uważnie śledził temat to byś nawet nie pisnął. Poza tym, jestem rozgarniętym człowiekiem i wiem gdzie jest Cardiff, a przynajmniej podejrzewam.
Poza tym co z Ciebie za admin jak tu nawet "prawej reki" nie masz? A jak spali się zasilacz? Albo właśnie wylewają się kondensatory na płycie?
[/OT]
@ Maciek: Dobrze prawisz, nic dodać nic ująć. Tak czy siak nie są to problemy "łatwe"
@ pectosol: patrz post Macka, poza tym wygląda mi to na problem software'owy...

_________________
| ArchLinux X64 2.6.29-6 (Custom) @ IBM eServer 235
| Intel Xeon 2,4GHz (x2) : 2GB RAM : 2x36GB SCSI (RAID1)
| httpd2.6 mysql exim dhcpd named proftpd stats niceshaper06
| WAN: 35|35 mb/s (GTS) @ 500+ hosts

pewnie racja...zwłaszcza że mrtg sam w sobie podbija wartość użycia CPU, ale...
w mojej okolicy właśnie obalam mit że "radiówka" daje marny net,
dlatego dokładam wszelkich starań aby chodziła tak jak "po kablu",
a znam takich co tylko dokładają nowych userów bo twierdzą "że im się jeszcze DSL nie wysycił..."

Pozatym mam jeszcze jeden serwer w sieci który udaje normalnego usera i mierzy kilka parametrów np ping do paru hostów , up i download, jitter i jeszcze kilka innych.
Z obserwacji wynika że jeśli użycie CPU na routerze osiąa wartości szczytowe to wszystkie w/w parametry ulegają poorszeniu.



nie ma, nie było, nie będzie.


druga połowa zgoda...właśnie pisze skrypt
ale z "... ręcznie ..." no nie mogę sie zodzić, niech komputer się męczy (ale nie ten który właśnie obserwuję ).


Pewnie i tu racja ale bez niego to wszytko było by bez sensu

BTW: do tej pory nikt mi nie wyjaśnił dlaczego nice odpalany z "palca" używa o 70% więcej CPU niż odpalany z crona.
Muszę przyznać że zademonstrowane wykresy są tylko dlatego tak niskie bo niecshepera odpalam/restartuje z crona...bez tego użycie CPU wzrośnie na 100%
Jako ciekawostkę mogę dodać że używam niceshapera 0.5.2 z parametrem reload 2s na słabym sprzęcie pII@500

w takiej konfiuracji ten router chodzi już od kilkunastu miesięcy z mniej więcej takim samym uptimem - więc raczej skreślam tą ewentualność



Tak właśnie zrobię.
Myślałem tylko że są jakieś "narzędzia" ułatwiające sprawdzenie.
mrtg jest takim narzędziem mniej lub bardziej dokładnym, które daje sygnał że coś jest nie tak.

Dlatego pytam speców tego distro czy są narzędzia precyzyjniejsze, aby "wyrwać chwasta" ?

Nalezy zauwazyc, że czesto miernik powoduje zly pomiar poniewaz wplywa na mierzona wartosc i tak jest w przypadku mrtg, co by o nim nie mowic jest bardzo procesorożerny.
warto wydluzyc przerwe miedzy pomiarami z 5 do 15 minut, co prawda wykres bedzie bardziej schodkowy ale zuzycie procesora mniejsze.

_________________
Nie jestem NEKROMANTĄ, nie wróżę z flaków!
Alkohol pity z umiarem nie szkodzi nawet w największych ilościach!
Przeczytaj nim zapytasz