Webshop veroorzaak zeer veel load op webserver

[Verwijderd]

Afgelopen vrijdag ontving ik het volgende mailtje van mijn internet provider:

"Beste klant,

Wij hebben melding gehad van een verhoogde load op onze webserver. Bij controle van deze melding viel uw hostingpakket op. Op de verschillende webservers processen waren processen van uw pakket te vinden. Om verder overlast te voorkomen hebben wij de website afgesloten d.m.v. een .htaccess file in de documentroot.

Bij controle van deze processen is ons helaas niet duidelijk geworden wat de oorzaak van deze hoge load en aantal processen. Dit soort gedrag van website zien wij over het algemeen alleen voorkomen bij gehackte websites. Dit voornamelijk door een lek in onveilige software (versies) zoals bijv.: Joomla, E107 of Wordpress of module hiervan.

Ondanks het feit dat wij niet direct de oorzaak aan kunnen wijzen willen wij u natuurlijk verzoeken onderzoek te doen naar de oorzaak van deze vele processen. Zoals aangegeven is een CMS altijd verdachte nummer 1.

Graag direct actie ondernemen en dit terug koppelen zodat wij dit ticket kunnen afhandelen.

Van deze melding wordt notitie gemaakt onder uw klantnummer.

Zie voor meer informatie omtrent onze Abuse regels onze AUP (Acceptable Use Policy):
http://www.pcextreme.nl/abuse/

Wij hopen op uw medewerking betreffende deze melding.
================================
Voorbeeld processen op een willekeurige webserver.
================================
root@web08:~# ps aux --sort rss |egrep 8077
root 22227 0.0 0.0 7628 888 pts/1 S+ 14:27 0:00 egrep --color=auto 8077
8077 18050 24.6 3.4 1120940 569488 ? R 14:11 3:52 /usr/sbin/apache2 -k start
8077 19771 18.7 3.4 1120992 569872 ? R 14:19 1:19 /usr/sbin/apache2 -k start
8077 19215 21.3 3.4 1121008 570020 ? R 14:16 2:11 /usr/sbin/apache2 -k start
8077 19223 16.5 3.4 1121008 570132 ? R 14:16 1:41 /usr/sbin/apache2 -k start
8077 18541 19.8 3.4 1121076 570616 ? R 14:13 2:36 /usr/sbin/apache2 -k start
8077 16658 29.7 3.4 1123316 571384 ? R 14:05 6:28 /usr/sbin/apache2 -k start
8077 15073 34.3 3.5 1125312 571808 ? R 13:59 9:32 /usr/sbin/apache2 -k start
8077 14815 38.8 3.5 1125556 572384 ? R 13:57 11:19 /usr/sbin/apache2 -k start
8077 17942 22.9 3.5 1123360 572592 ? R 14:10 3:43 /usr/sbin/apache2 -k start
8077 16694 28.3 3.5 1128232 573288 ? R 14:05 6:08 /usr/sbin/apache2 -k start
8077 18431 21.6 3.5 1126944 573948 ? R 14:13 2:57 /usr/sbin/apache2 -k start
8077 17093 23.6 3.5 1126224 574036 ? R 14:07 4:36 /usr/sbin/apache2 -k start
8077 15736 34.2 3.5 1126644 574228 ? R 14:01 8:44 /usr/sbin/apache2 -k start
8077 19792 19.7 3.5 1127944 575488 ? R 14:19 1:23 /usr/sbin/apache2 -k start
8077 17095 27.2 3.5 1127476 577024 ? R 14:07 5:18 /usr/sbin/apache2 -k start
8077 17168 23.8 3.5 1127484 577364 ? R 14:07 4:35 /usr/sbin/apache2 -k start
8077 17173 25.0 3.5 1128776 577952 ? R 14:07 4:47 /usr/sbin/apache2 -k start
8077 15747 36.8 3.5 1132704 578512 ? R 14:01 9:23 /usr/sbin/apache2 -k start
8077 15906 33.8 3.5 1130176 579732 ? R 14:02 8:25 /usr/sbin/apache2 -k start
8077 17778 22.4 3.5 1132156 580008 ? R 14:10 3:48 /usr/sbin/apache2 -k start
8077 19254 19.7 3.5 1132024 580692 ? R 14:16 1:59 /usr/sbin/apache2 -k start
8077 15660 33.2 3.6 1139912 588748 ? R 14:01 8:34 /usr/sbin/apache2 -k start
8077 18544 23.9 3.6 1140060 588792 ? R 14:13 3:08 /usr/sbin/apache2 -k start
8077 18526 18.4 3.6 1146128 592332 ? R 14:13 2:27 /usr/sbin/apache2 -k start
8077 16427 28.1 3.6 1145632 593060 ? R 14:04 6:15 /usr/sbin/apache2 -k start
8077 17796 23.3 3.6 1146572 594684 ? R 14:10 3:57 /usr/sbin/apache2 -k start
8077 14094 36.6 3.6 1155796 601168 ? R 13:54 11:52 /usr/sbin/apache2 -k start
8077 19325 19.1 3.6 1154344 603100 ? R 14:17 1:51 /usr/sbin/apache2 -k start
8077 13925 36.9 3.7 1161312 605684 ? R 13:53 12:13 /usr/sbin/apache2 -k start
8077 15888 24.9 3.7 1163876 610936 ? R 14:02 6:12 /usr/sbin/apache2 -k start
root@web08:~# getent passwd |egrep 8077
vhost0003077:*:8077:5000:vhost0003077:/home/vhosting/i/vhost0003077:/bin/false

root@web10:~# ps aux --sort rss |egrep 8077
root 22631 1.0 0.0 7628 888 pts/1 S+ 14:29 0:00 egrep --color=auto 8077
8077 18050 24.0 3.4 1120940 569488 ? R 14:11 4:21 /usr/sbin/apache2 -k start
8077 19771 19.0 3.4 1120992 569872 ? R 14:19 1:48 /usr/sbin/apache2 -k start
8077 19215 21.2 3.4 1121008 570020 ? R 14:16 2:41 /usr/sbin/apache2 -k start
8077 19223 17.5 3.4 1121008 570132 ? R 14:16 2:13 /usr/sbin/apache2 -k start
8077 18541 19.5 3.4 1121076 570616 ? R 14:13 3:02 /usr/sbin/apache2 -k start
8077 16658 28.9 3.4 1123316 571384 ? R 14:05 6:59 /usr/sbin/apache2 -k start
8077 15073 32.7 3.5 1125312 571808 ? R 13:59 9:54 /usr/sbin/apache2 -k start
8077 14815 37.4 3.5 1125556 572384 ? R 13:57 11:48 /usr/sbin/apache2 -k start
8077 17942 22.5 3.5 1123360 572592 ? R 14:10 4:12 /usr/sbin/apache2 -k start
8077 16694 27.0 3.5 1128232 573288 ? R 14:05 6:30 /usr/sbin/apache2 -k start
8077 18431 21.5 3.5 1126944 573948 ? R 14:13 3:28 /usr/sbin/apache2 -k start
8077 17093 23.5 3.5 1126224 574036 ? R 14:07 5:09 /usr/sbin/apache2 -k start
8077 15736 33.0 3.5 1126644 574228 ? R 14:01 9:13 /usr/sbin/apache2 -k start
8077 19792 19.7 3.5 1127944 575488 ? R 14:19 1:52 /usr/sbin/apache2 -k start
8077 17095 26.5 3.5 1127476 577024 ? R 14:07 5:49 /usr/sbin/apache2 -k start
8077 17168 23.2 3.5 1127484 577364 ? R 14:07 5:00 /usr/sbin/apache2 -k start
8077 17173 24.6 3.5 1128776 577952 ? R 14:07 5:19 /usr/sbin/apache2 -k start
8077 15747 35.6 3.5 1132704 578512 ? R 14:01 9:56 /usr/sbin/apache2 -k start
8077 15906 32.6 3.5 1130176 579732 ? R 14:02 8:54 /usr/sbin/apache2 -k start
8077 17778 22.2 3.5 1132156 580008 ? R 14:10 4:18 /usr/sbin/apache2 -k start
8077 19254 20.0 3.5 1132024 580692 ? R 14:16 2:30 /usr/sbin/apache2 -k start
8077 15660 32.4 3.6 1139912 588748 ? R 14:01 9:08 /usr/sbin/apache2 -k start
8077 18544 23.2 3.6 1140060 588792 ? R 14:13 3:37 /usr/sbin/apache2 -k start
8077 18526 18.3 3.6 1146128 592332 ? R 14:13 2:52 /usr/sbin/apache2 -k start
8077 16427 27.5 3.6 1145632 593060 ? R 14:04 6:47 /usr/sbin/apache2 -k start
8077 17796 22.9 3.6 1146572 594684 ? R 14:10 4:26 /usr/sbin/apache2 -k start
8077 14094 35.4 3.6 1155796 601168 ? R 13:54 12:21 /usr/sbin/apache2 -k start
8077 19325 19.9 3.6 1154344 603100 ? R 14:17 2:24 /usr/sbin/apache2 -k start
8077 13925 35.7 3.7 1161312 605684 ? R 13:53 12:42 /usr/sbin/apache2 -k start
8077 15888 24.7 3.7 1163876 610936 ? R 14:02 6:46 /usr/sbin/apache2 -k start"

ik maak gebruik van iVENDi software. Deze software draait op CS Cart (http://www.cs-cart.com/)

Naar mijn weten draai ik de nieuwste versie van CS cart 3.0.6.

Heeft er iemand ervaring met bovenstaande processen. Wat betekenen deze precies? Het is voor mij echt een raadsel. Welke stappen kan ik zelf ondernemen om de website weer in de lucht te krijgen en de processen die de extreme load veroorzaken te stoppen? Tips zijn erg welkom!

[Lampje]

De boel cachen? ;-)

[Juup]

Als je echt gehackt bent is er maar 1 oplossing: alles deleten / formatteren / nieuwe VM instance en helemaal vers alles opnieuw installeren, daarna je data terugzetten.

Dan monitoren wat er gebeurt.

Hoeveel bezoekers heb je ongeveer per uur?
Hoeveel hits per uur?

Post eens een stuk access log en error log?

[Verwijderd]

Jaaap,

de webshop is nog niet zo lang online. Via google analytics komen er gemiddeld 25 unieke bezoekers per dag.
Dit was ook het geval op de dag dat ik het bericht ontving van de host.

Hoe kom ik aan een access log of een error log?

[André]

Verwijderd schreef op maandag 24 juni 2013 @ 20:40:
Jaaap,

de webshop is nog niet zo lang online. Via google analytics komen er gemiddeld 25 unieke bezoekers per dag.
Dit was ook het geval op de dag dat ik het bericht ontving van de host.

Hoe kom ik aan een access log of een error log?

Heb je een login voor Plesk/Direct Admin oid van je hosting partner gekregen? Daar ergens staat ook wel linkje naar je logs

[Verwijderd]

Deze gegevens heb ik kunnen vinden via het controle paneel van de host. Voor zover ik weet kan ik helaas geen errorlogs krijgen van mijn host (pcextreme).

[scorpie]

Access logs vind je meestal in /var/logs. Dan even zoeken naar een /var/logs/error.log of /var/logs/access.log

De precieze locatie kun je overigens ook vinden in je httpd.conf of apache2.conf (In elk geval in de config file van Apache).

[TheNephilim]

Nog geen 2.000 requests per dag, dat zou geen moeite moeten zijn voor een beetje webserver. Hoeveel producten heb je in je webwinkel?

[MueR]

Dit heeft weinig met Webdesign, Markup & Clientside Scripting te maken, dus dit zet ik even door naar Serversoftware en Windows Servers

[Verwijderd]

Ik heb de host-partij gevraagd op error logs. Even de reactie afwachten.

Ik kan via de website van pcextreme inloggen. Daar kan ik mijn hostingpakket bekijken. De enige informatie die ik daar kan vinden zijn de grafieken en tabellen die ik hier heb gepost.

Er staan ongeveer 270 producten in de webwinkel. Waarbij er wel een aantal zijn die "ingewikkeld" in elkaar steken. Dat wil zeggen veel keuze opties. Maar achter de schermen in het CMS betekend dit dat er veel zogenaamde verboden combinaties zijn aangemaakt. Maar lijkt me dat dit niet een dergelijke storing kan veroorzaken.

Die apache2.conf en httpd.conf moeten ergens op de webserver staan? Kan ik die via filezilla benaderen?

[Compizfox]

@TS: Daar kun je niet bij, want ik heb het idee dat je shared hosting hebt en geen dedicated server of een VPS.

[ Voor 8% gewijzigd door Compizfox op 26-06-2013 22:26 ]

[Bastien]

Kunnen verschillende dingen zijn. Ik ken het pakket niet, maar zo te lezen kan ie best wat resources verbruiken. Op shared hosting, wat je denk ik hebt, is dat meestal vrij snel een probleem. Als een pagina ophalen veel queries nodig heeft, trekt dat redelijk snel een wissel op bijvoorbeeld geheugen en beschikbare CPU. Dat zie je dan in een hogere load terug. Als je grote plaatjes hebt ipv kleintjes, idem. Het moet allemaal verwerkt worden en als de beschikbare resources niet al te hoog zijn krijg je snel filevorming (want je hebt aardig wat apacheprocessen draaien) en klachten.

Toen je nog wel bij de site kon, duurde het dan meerdere seconden om een pagina te laden? Want dat zegt dan meestal wel genoeg.

Misschien dat je anders op het forum van de cs-cart nog wat nuttige tweaks tegenkomt.

Heb hetzelfde gehad met een Coppermine Gallery fotosite, die draait nu zonder problemen op een VPS maar op shared hosting vroeger was altijd gezeik van de hoster.

[Verwijderd]

Het klop idd dat ik gebruik maak van een shared hosting webserver. Dit werd mij althans verteld door de medewerker van pcextreme.

Tevens was zowel het CMS als de webshop traag met pagina's laden. Maar ook het invoeren in het CMS moest je soms 15-30 sec wachten als je ergens op had geklikt.

Dus wellicht zijn de problemen opgelost als ik over zou stappen naar een VPS hosting?

[Verwijderd]

De overzichten die je post gaat over het data verbruik. Maar het zijn de (php)scripts die veel cpu load veroorzaken.
Als je met zo'n kleine webshop al zulke problemen hebt, betaal je je scheel aan een VPS oplossing.
Zijn er meerdere met CScart die het zelfde ervaren? Dan komt er mss wel een update uit. Heb je een module geïnstalleerd? Kijk als hier een update voor is. Zelf een add-on/module geschreven? Zit hier mogelijk iets continue te loopen?

260 artikelen stelt niets voor. Zelf ook tijdje OScommerce website onderhouden bij PCextreme. Over de 1500 artikelen, met allerlei keuzes. Nooit problemen gehad met performance oid.

[gitaarwerk]

Ik heb zoiets ook gehad eens. Wordpress site met meertalige plugin. Dingetje was..er stond een vinkje aan voor debug mode. En toen kwamen er ineens 10 mensen tegelijk op..... blijkbaar voerde het script ipv een stuk of 60 queries ineens 6000 queries uit.

Misschien even checken of bij jou niet het geval is dat er ergens een debug mode aan staat. Uiteraard kom je dit tegen wel in je logs. Wat je evt ook kan doen is een debug scriptje draaien welke je processen telt. wellicht is dat al een handige start?

[mpijnen]

Ook al ga je hiervoor naar een eigen server, dan blijf je tegen hetzelfde probleem aanlopen!
Als ik de processen bekijk dan wordt er gigantisch veel CPU gebruikt voor een simpele webshop.

Voor het aantal bezoekers dat jou site momenteel heeft zou caching eigenlijk helemaal niet nodig moeten zijn. Ik denk dat je het beste een ervaren programmeur kunt inschakelen. Je kunt zelf natuurlijk ook op het forum gaan zoeken maar dat kost wellicht meer tijd....

[GlowMouse]

Wat je hier ziet is dat er minimaal 30 elementen tegelijk worden opgevraagd, en gelet op het cpu-gebruik zijn dat allemaal php-files. Dat kan niet als je maar 4000 hits per dag hebt, tenzij één request erg lang duurt of je veel meer hits hebt gekregen.