Ubuntu 14.04 x64 server zeer traag

[Slechdt]

-

[ Voor 100% gewijzigd door Slechdt op 06-01-2020 17:58 ]

[TommieW]

Ik zie dat je SSH hebt draaien op de standaard poort 22. In het algemeen is het verstandig om SSH op een poort boven de 1024 te laten draaien. Er zijn nogal veel scriptkiddies die met een dictionary attack binnen proberen te komen. Verder is het natuurlijk wel handig om op zo'n server root login via SSH uit te schakelen, maar dat is vaak de default. Password login uitzetten en alleen inloggen via keys is ook geen slecht idee. Maar dat is, zolang (nog) niemand binnen heeft kunnen komen, geen oorzaak van de traagheid.

RAM usage is vaak niet echt een probleem. Meer informatie over RAM usage onder Linux kan je vinden op deze site. Maak ook nog eens zo'n screenshot, maar dan gesorteerd op memory usage.

Je zegt dat de "server super traag is". Wat bedoel je hier precies mee? Is de website traag, is toegang via SSH traag? Wat bedoel je precies?

[Slechdt]

-

[ Voor 100% gewijzigd door Slechdt op 06-01-2020 17:58 ]

[Hero of Time]

Het geheugengebruik is niet abnormaal. Ook dat je SSH sessie geen traagheid vertoont geeft je direct de clue: het is je webapplicatie. Zie ook de eerste 4 entries in je htop screenshot. Helaas heb je 'm nogal smal gehouden, waardoor niet te zien is wat het nou precies uitvoert, maar het hoort iig niet. Alles van je website wordt via apache uitgevoerd, aparte php-fpm processen die door iemand anders wordt uitgevoerd, te weten serverpil (waarschijnlijk een langere naam, het wordt afgekapt) hoort niet.

Ik zie ook nginx draaien en iets dat in /opt/sp/apache staat. Heb je nou nginx EN Apache httpd draaien? Hoe heb je de boel opgezet? Apache hoort niet vanuit /opt te komen, tenzij je een of andere 'installatie howto' hebt gevolgd dat gebruik maakt van pre-build binaries ipv de distro packages.

[Slechdt]

-

[ Voor 100% gewijzigd door Slechdt op 06-01-2020 17:59 ]

[narotic]

Slechdt schreef op zondag 17 januari 2016 @ 20:28:
"Normaal" gesproken geeft het command free -m onderstaande ongeveer weer. Maar na een tijd gaat op de bovenste regel de used richting de 1900+. Dit lijkt mij dat memory niet wordt teruggeven.

code:

.            total       used       free     shared    buffers     cached
Mem:          2001        948       1053         65         24        249
-/+ buffers/cache:        673       1328
Swap:          511          0           511

Het is juist de bedoeling dat "used" in de bovenste regel richting de 2000 gaat. Het is zonde om beschikbaar geheugen niet te gebruiken, vandaar dat Linux dit vrije geheugen in zal zetten voor buffer/file caches. Het geheugengebruik zal daarom dus langzaam oplopen richting de max naarmate meer files aangesproken worden. Zodra een programma geheugen nodig heeft zullen deze caches echter onmiddelijk weer vrijgegeven worden.

Als het probleem daadwerkelijk aan het geheugen lag dan zou je dat zowel aan de tweede regel (vrij geheugen exclusief de cache/buffers) en aan de swap kunnen zien. Als vuistregel kun je over het algemeen aanhouden dat je pas geheugenproblemen hebt zodra je regelmatig je swap gebruikt.

Het lijkt niet waarschijnlijk aangezien je SSD storage hebt, maar sluit ook I/O niet direct uit als mogelijke bron van je probleem. De beste tool om dit in de gaten te houden is voor zover ik weet iostat (uit het sysstat package). De meest directe indicator van problemen is een hoog %iowait.

[ Voor 3% gewijzigd door narotic op 18-01-2016 10:41 ]

[Hero of Time]

Slechdt schreef op zondag 17 januari 2016 @ 23:18:
Beste Hero of Time,

klopt ik heb gebruik gemaakt van een standaard installatie vanuit serverpilot. Zij installeren inderdaad nginx en apache. https://serverpilot.io/features#configuration

In ieder geval even een support ticket naar hun gestuurd betreffende die processen.

Die manier is net als vele web-based beheer portals inefficiënt en generiek, waardoor je dus zaken kan krijgen die je niet wilt. Zo het is het draaien van nginx en Apache wel mogelijk, maar onlogisch. Want waarom zou je twee webservers draaien op een server als je maar 1 site host.

[igmar]

En wat zegt iotop ? Je memusage geeft aan dat er geen sprake is van swap, dus geheugen is niet het issue. Blijft over de IO performance.

[Slechdt]

-

[ Voor 99% gewijzigd door Slechdt op 06-01-2020 17:59 ]

[Blokker_1999]

Alleen heb je nu gewoon een API uitgeschakeld en zit je dus eigenlijk nog altijd bezig met symptoombestrijding. De root cause van het probleem is nog altijd niet gevonden. En wie weet kome je op een dag een plugin tegen die deze API wel degelijk nodig heeft en kan je weer verder gaan zoeken.

Is het daarom niet beter om, desnoods op rustigere momenten, verder te zoeken naar de kernoorzaak van dit probleem?

Dat gezegd zijnde, is het zeker geen slecht idee om, als het kan, XML-RPC inderdaad uit te schakelen.

[Slechdt]

-

[ Voor 100% gewijzigd door Slechdt op 06-01-2020 17:59 ]

[Hero of Time]

Installeer en configureer iptables om flood requests tegen te gaan. Want zo te horen had je een DoS te pakken die gelukkig voor jou niet zo snel ging dat je site plat ging. Het constant aanroepen van de Wordpress API via XML-RPC klinkt ook als een hack poging van een script kiddie. Beveilig je server dus voordat je winkel compromised is en je klantgegevens op straat liggen.

[Thc_Nbl]

TommieW schreef op zondag 17 januari 2016 @ 20:41:
Ik zie dat je SSH hebt draaien op de standaard poort 22. In het algemeen is het verstandig om SSH op een poort boven de 1024 te laten draaien.

onzin... 22 is prima, gewoon geen root toelaten.
Draai al meer dan 16 jaar op poort 22, nog nooit een hack gehad.

Ik zou alle aandacht op de web omgeving richten.
zoals Heroes al aan geeft, beveilig je webserver beter.

mod-security zit standaard in debian, en hier een prima start.

http://www.pontikis.net/blog/securing-web-applications-with-modsecurity

[Slechdt]

-

[ Voor 100% gewijzigd door Slechdt op 06-01-2020 17:59 ]