Serverabschaltung durch Provider ohne Vorwarnung da zu viel HD Last???

M

Muenzenwert

New Member
Hallo zusammen,

mein Provider hat gestern ohne Vorwarnung meinen Server (Dedicated Virtual Managed Server) abgeschaltet und mir eine Mail geschrieben..
Projekt: Webseite über Münzen und deren aktuelle Preise, PHP eigene Programme, MySql DB ca. 10gb, ca. 30 000 000 Verkäufe gespeichert, ca. 30 000 Page Views am Tag.
Projekt läuft seit 2 Jahren bei diesem Provider, keine Änderungen bei den Programmen seit 2 Monaten..
Es läuft auch ein Forum, wobei das nicht wirklich genutzt wird und auch nicht wirklich intern verlinkt ist, Scripte sind aber am Server.

CPU Last ist normalerweise bei ca. 6%, RAM Auslastung so bei 60% (8GB / MySQL Cache 4GB)

Logfile: Ca. 35 Einträge im Logfile in 40 Minuten.....

Kann Jemand in diesem Logfile etwas sehen was die Infrastruktur des Providers belastet?
Eine Menge von Fehlern sehen die darauf hinweisen, daß meine Scripte schlecht sind?
Kann Jemand einen Provider empfehlen der so ein Projekt hostet und nicht mal schnell den Server abschaltet? Ich lebe von diesem Projekt und so eine Abschaltung ist (neben der Ausfallzeit) auch fürs SEO nicht gerade gut...

Danke für Hinweise oder Tips :)


Mail:

Guten Tag Herr XXXXXX,

Leider mussten wir Ihren Server herunter fahren, weil dieser unsere Infrasturktur übermassen beansprucht!

Er belastet das Disk-Array im Terrabyte - Bereich und so haben wir uns den Server heute kurz angeschaut und eine Menge von Fehlern festgestellt,
die daraufhin weisen, daß die Software nicht in einem einwandfreien Zustand sich befindet!

Ein nur kleiner Auszug aus den Fehlermeldungen:
Code: 
[Mon Apr 29 14:25:16.662333 2019] [fcgid:warn] [pid 1584827] [client 49.147.195.16:35954] mod_fcgid: stderr: PHP Fatal error: Maximum execution time of 120 seconds exceeded in /var/www/vhosts/muenzenwert.de/httpdocs/Functions/translate.
php on line 46
[Mon Apr 29 14:27:26.882518 2019] [fcgid:warn] [pid 1585805] [client 110.54.251.242:38318] mod_fcgid: stderr: PHP Fatal error: Maximum execution time of 120 seconds exceeded in /var/www/vhosts/muenzenwert.de/httpdocs/Functions/translate
.php on line 46
[Mon Apr 29 14:31:12.276700 2019] [fcgid:warn] [pid 1585927] (32)Broken pipe: [client 213.32.112.206:48442] mod_fcgid: ap_pass_brigade failed in handle_request_ipc function
[Mon Apr 29 14:32:26.636256 2019] [fcgid:warn] [pid 1585927] [client 2.86.240.200:50058] mod_fcgid: stderr: PHP Notice: Undefined v, referer:https://googleads.g.doubleclick.net/pagead/ads?client=ca-pub-3852867109683769&output=html&h=14
17&slotname=4946017576&adk=34963144&adf=3343579886&w=384&cr_col=1&cr_row=12&fwrn=2&lmt=1556530321&rafmt=9&guci=1.2.0.0.2.2.0.0&format=384x1417&url=https%3A%2F%2Fwww.muenzenwert.de%2FEN%2FsucheMuenzenWert.php®ion=responsive_resize&flas
h=0&crui=mobile_banner_image_sidebyside&fwr=0&pra=3&wgl=1&fa=16&adsid=AGt39rToz7GOTl6rJIYGuuTLOqUQKx4D59XLmgVPmZ6XBBrwaivZZNyHu-a7wQEPNu2P&dt=1556541120478&bpp=1075&fdt=1079&idt=-M&shv=r20190422&cbv=r20190131&saldr=aa&abxe=1&nras=1&corre
lator=8380877604865&frm=20&pv=1&ga_vid=13664804.1556540805&ga_sid=1556541094&ga_hid=43816407&ga_fc=0&iag=0&icsg=11013803&dssz=41&mdo=0&mso=0&u_tz=180&u_his=13&u_java=0&u_h=480&u_w=320&u_ah=460&u_aw=320&u_cd=32&u_nplug=0&u_nmime=0&adx=8&a
dy=1203&biw=400&bih=465&scr_x=0&scr_y=0&eid=21060853%2C21063245&oid=3&ref=https%3A%2F%2Fwww.muenzenwert.de%2FEN%2FsucheMuenzenWert.php&loc=https%3A%2F%2Fwww.muenzenwert.de%2FEN%2FsucheMuenzenWert.php&rx=0&eae=0&fc=656&brdim=0%2C0%2C0%2C0
%2C320%2C0%2C0%2C0%2C400%2C551&vis=1&rsz=%7C%7Cs%7C&abl=NS&ppjl=f&fu=1168&bc=1&jar=2019-04-29-12&ifi=6&uci=a!6&xpc=mL7eAkmHNR&p=https%3A//www.muenzenwert.de&dtd=1146
[Mon Apr 29 14:32:26.723766 2019] [fcgid:warn] [pid 1585927] [client 2.86.240.200:50058] mod_fcgid: stderr: ariable: chartTitleCountry in /var/www/vhosts/muenzenwert.de/httpdocs/EN/Informationen/euro_list_overview.php on line 448, refere
r: https://googleads.g.doubleclick.net/pagead/ads?client=ca-pub-3852867109683769&output=html&h=1417&slotname=4946017576&adk=34963144&adf=3343579886&w=384&cr_col=1&cr_row=12&fwrn=2&lmt=1556530321&rafmt=9&guci=1.2.0.0.2.2.0.0&format=384x14
17&url=https%3A%2F%2Fwww.muenzenwert.de%2FEN%2FsucheMuenzenWert.php®ion=responsive_resize&flash=0&crui=mobile_banner_image_sidebyside&fwr=0&pra=3&wgl=1&fa=16&adsid=AGt39rToz7GOTl6rJIYGuuTLOqUQKx4D59XLmgVPmZ6XBBrwaivZZNyHu-a7wQEPNu2P&d
t=1556541120478&bpp=1075&fdt=1079&idt=-M&shv=r20190422&cbv=r20190131&saldr=aa&abxe=1&nras=1&correlator=8380877604865&frm=20&pv=1&ga_vid=13664804.1556540805&ga_sid=1556541094&ga_hid=43816407&ga_fc=0&iag=0&icsg=11013803&dssz=41&mdo=0&mso=0
&u_tz=180&u_his=13&u_java=0&u_h=480&u_w=320&u_ah=460&u_aw=320&u_cd=32&u_nplug=0&u_nmime=0&adx=8&ady=1203&biw=400&bih=465&scr_x=0&scr_y=0&eid=21060853%2C21063245&oid=3&ref=https%3A%2F%2Fwww.muenzenwert.de%2FEN%2FsucheMuenzenWert.php&loc=h
ttps%3A%2F%2Fwww.muenzenwert.de%2FEN%2FsucheMuenzenWert.php&rx=0&eae=0&fc=656&brdim=0%2C0%2C0%2C0%2C320%2C0%2C0%2C0%2C400%2C551&vis=1&rsz=%7C%7Cs%7C&abl=NS&ppjl=f&fu=1168&bc=1&jar=2019-04-29-12&ifi=6&uci=a!6&xpc=mL7eAkmHNR&p=https%3A//ww
w.muenzenwert.de&dtd=1146
[Mon Apr 29 14:34:29.185639 2019] [fcgid:warn] [pid 1586195] (32)Broken pipe: [client 87.180.185.57:52860] mod_fcgid: ap_pass_brigade failed in handle_request_ipc function, referer:https://www.google.de/
[Mon Apr 29 14:41:10.454363 2019] [fcgid:warn] [pid 1586485] (32)Broken pipe: [client 213.32.112.206:35764] mod_fcgid: ap_pass_brigade failed in handle_request_ipc function
[Mon Apr 29 14:41:10.974341 2019] [fcgid:warn] [pid 1585797] [client 49.147.195.16:59796] mod_fcgid: stderr: PHP Fatal error: Maximum execution time of 120 seconds exceeded in /var/www/vhosts/muenzenwert.de/httpdocs/Functions/translate.
php on line 46
[Mon Apr 29 14:45:12.940257 2019] [fcgid:warn] [pid 1585798] [client 49.147.195.16:36966] mod_fcgid: stderr: PHP Fatal error: Maximum execution time of 120 seconds exceeded in /var/www/vhosts/muenzenwert.de/httpdocs/Functions/translate.
php on line 46
[Mon Apr 29 14:47:28.868454 2019] [fcgid:warn] [pid 1584899] [client 49.147.195.16:37842] mod_fcgid: stderr: PHP Fatal error: Maximum execution time of 120 seconds exceeded in /var/www/vhosts/muenzenwert.de/httpdocs/Functions/translate.
php on line 57
[Mon Apr 29 14:48:40.064601 2019] [fcgid:warn] [pid 1585662] (104)Connection reset by peer: [client 49.147.195.16:35600] mod_fcgid: error reading data from FastCGI server
[Mon Apr 29 14:48:40.065210 2019] [core:error] [pid 1585662] [client 49.147.195.16:35600] End of script output before headers: testSoldCoin.php
[Mon Apr 29 14:49:11.060969 2019] [fcgid:warn] [pid 1587100] (32)Broken pipe: [client 213.32.112.206:46876] mod_fcgid: ap_pass_brigade failed in handle_request_ipc function
[Mon Apr 29 14:49:38.132819 2019] [fcgid:warn] [pid 1586815] [client 49.147.195.16:39198] mod_fcgid: stderr: PHP Fatal error: Maximum execution time of 120 seconds exceeded in /var/www/vhosts/muenzenwert.de/httpdocs/Functions/translate.
php on line 53
[Mon Apr 29 14:51:48.847857 2019] [fcgid:warn] [pid 1586819] [client 49.147.195.16:40310] mod_fcgid: stderr: PHP Fatal error: Maximum execution time of 120 seconds exceeded in /var/www/vhosts/muenzenwert.de/httpdocs/Functions/coinExtrac
tUID.php on line 752
[Mon Apr 29 14:56:51.635851 2019] [fcgid:warn] [pid 1586815] (32)Broken pipe: [client 88.73.158.113:57896] mod_fcgid: ap_pass_brigade failed in handle_request_ipc function, referer:https://googleads.g.doubleclick.net/pagead/ads?client=c
a-pub-3852867109683769&output=html&h=1587&slotname=4946017576&adk=554965057&adf=4272038720&w=434&cr_col=1&cr_row=12&fwrn=2&ebfaca=1&lmt=1556542138&rafmt=9&guci=1.2.0.0.2.2.0.0&format=434x1587&url=https%3A%2F%2Fwww.muenzenwert.de%2FEN%2FM
uenzkatalog%2FDeutschland%2F3.Reich%2F2_Mark%2F2_Mark_1936-1939_C615.html&flash=0&crui=mobile_banner_image_sidebyside&fwr=0&wgl=1&adsid=AGt39rS7l8yL_hXyV8duR6FwSHhy9xicMPjg1LCF2y35OvbAXp2zbbR1yOkynYnve2SRULKLK3s0b2DKMOoXAU5Q676q9P-uj_5Eg
A&dt=1556542138339&bpp=57&bdt=2171&fdt=61&idt=-M&shv=r20190422&cbv=r20190131&saldr=aa&abxe=1&prev_fmts=450x280%2C450x250_0ads_al%2C450x250_0ads_al%2C450x375&correlator=8300380315421&frm=20&pv=1&ga_vid=2130942325.1548027599&ga_sid=1556542
137&ga_hid=150137623&ga_fc=0&iag=0&icsg=656298&dssz=20&mdo=0&mso=0&u_tz=120&u_his=3&u_java=0&u_h=640&u_w=360&u_ah=640&u_aw=360&u_cd=24&u_nplug=0&u_nmime=0&adx=8&ady=8665&biw=450&bih=700&scr_x=0&scr_y=0&eid=21060853%2C21063245%2C20040010%
2C423550200&oid=3&ref=https%3A%2F%2Fwww.muenzenwert.de%2FEN%2FMuenzkatalog%2FDeutschland%2F3.Reich%2F2_Mark_Versions_P15.html&rx=0&eae=0&fc=660&brdim=0%2C0%2C0%2C0%2C360%2C0%2C360%2C560%2C469%2C730&vis=1&rsz=%7C%7CeEbr%7C&abl=CS&ppjl=f&p
fx=0&fu=1168&bc=15&osw_key=1576849218&ifi=5&uci=5.raswap4hkocb&xpc=UyCBNwe5IZ&p=https%3A//www.muenzenwert.de&dtd=83
[Mon Apr 29 14:59:12.002126 2019] [fcgid:warn] [pid 1586194] (32)Broken pipe: [client 213.32.112.206:60868] mod_fcgid: ap_pass_brigade failed in handle_request_ipc function
[Mon Apr 29 15:00:10.775529 2019] [fcgid:warn] [pid 1586819] (32)Broken pipe: [client 131.175.147.208:33400] mod_fcgid: ap_pass_brigade failed in handle_request_ipc function, referer:https://www.muenzenwert.de/EN/sucheMuenzenWert.php
[Mon Apr 29 15:00:34.915209 2019] [fcgid:warn] [pid 1586194] (32)Broken pipe: [client 84.145.171.163:34850] mod_fcgid: ap_pass_brigade failed in handle_request_ipc function, referer:https://www.muenzenwert.de/sucheMuenzenWert.php?search
=1+Mark+1990+BRD
[Mon Apr 29 15:02:49.055378 2019] [fcgid:warn] [pid 1587614] (32)Broken pipe: [client 195.90.21.32:39058] mod_fcgid: ap_pass_brigade failed in handle_request_ipc function, referer:www.muenzenwert.de
[Mon Apr 29 15:03:22.657830 2019] [fcgid:warn] [pid 1585817] [client 49.147.195.16:33882] mod_fcgid: stderr: PHP Fatal error: Maximum execution time of 120 seconds exceeded in /var/www/vhosts/muenzenwert.de/httpdocs/Functions/translate.
php on line 57
[Mon Apr 29 15:04:11.105783 2019] [:error] [pid 1587369] [client 40.77.167.86:41932] [client 40.77.167.86] ModSecurity: Warning. Matched phrase "../" at REQUEST_URI. [file "/etc/apache2/modsecurity.d/rules/owasp_modsecurity_crs_3-plesk/R
EQUEST-930-APPLICATION-ATTACK-LFI.conf"] [line "34"] [id "930110"] [rev "1"] [msg "Path Traversal Attack (/../)"] [data "Matched Data: ../ found within REQUEST_URI: /Muenzkatalog/.../BRD/.../5_DM_1975-2001_C642.html"] [severity "CRITICAL
"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "7"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-lfi"] [tag "OWASP_CRS/WEB_ATTACK/DIR_TRAVERSAL"] [hostname "www.muenzenwert.de"] [uri "/Muenzka
talog/.../BRD/.../5_DM_1975-2001_C642.html"] [unique_id "XMb2S9UgcNoAGDipT74AAAAA"]
[Mon Apr 29 15:04:11.106236 2019] [:error] [pid 1587369] [client 40.77.167.86:41932] [client 40.77.167.86] ModSecurity: Warning. Matched phrase "../" at REQUEST_URI. [file "/etc/apache2/modsecurity.d/rules/owasp_modsecurity_crs_3-plesk/R
EQUEST-930-APPLICATION-ATTACK-LFI.conf"] [line "34"] [id "930110"] [rev "1"] [msg "Path Traversal Attack (/../)"] [data "Matched Data: ../ found within REQUEST_URI: /muenzkatalog/.../brd/.../5_dm_1975-2001_c642.html"] [severity "CRITICAL
"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "7"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-lfi"] [tag "OWASP_CRS/WEB_ATTACK/DIR_TRAVERSAL"] [hostname "www.muenzenwert.de"] [uri "/Muenzka
talog/.../BRD/.../5_DM_1975-2001_C642.html"] [unique_id "XMb2S9UgcNoAGDipT74AAAAA"]
[Mon Apr 29 15:05:35.160061 2019] [fcgid:warn] [pid 1586194] [client 49.147.195.16:39530] mod_fcgid: stderr: PHP Fatal error: Maximum execution time of 120 seconds exceeded in /var/www/vhosts/muenzenwert.de/httpdocs/Functions/translate.
php on line 46


Für weitere Fragen stehen wir Ihnen jederzeit zur Verfügung.

Mit freundlichen Grüßen
xxxxxxxxxxxxxxx
 
Last edited by a moderator:
Ich verstehe, dass ein Provider sich um Belastungen kümmern muss, ich verstehe aber nicht wie man einen Server einfach abschalten kann...
HD Belastung kann nur durch zwei Dinge passieren
1. DB nun zu groß und passt nicht mehr in DB cache -> 8gb mehr Speicher und DB mehr Platz geben - wieder OK
2. Zu viele Besucher die zu viele Files öffnen beim Webseiten ansehen - das kann und will ich nicht ändern.. lebe ja von den Besuchern...
Die Programme schreiben / lesen keine Daten-Files - nur DB
Kann es sein, dass dem Provider es nun einfach zu viele Besucher sind und es sich nicht mehr rechnet?

Ich hätte kein Problem damit 50 oder 100 Euro mehr im Monat für einen größeren Server zu zahlen... bisher war es einfach nicht notwendig.. Server ist von der Technik her mit 6% CPU Last und 60% Speicherauslastung nicht wirklich am Limit

Die Frage ist: Was soll ich nun machen? So schnell kann ich Projekt nicht umziehen und wer weiß was der nächste Provider dann macht..
 
Aber mal was ganz anderes, wieso kommt der Provider an deine Logfiles die auf DEINEM Server liegen? Ich gehe mal davon aus das du Ihm keine Berechtigung gegeben hast sich an deinem Server anzumelden? Also ist es ja quasi ein unberechtigtes "eindringen"? Korrigiert mich wenn ich da falsch liege.
 
Ahhh das erklärt meine Frage natürlich. Ich würde mir ggf. auch nen neuen Provider suchen, Hetzner ist da eigentlich sehr gut.
 
@Milchbroetchen -> Managed :)

OK ich werde mich einmal umsehen bei Hetzner.
Richtiger Server wäre vermutlich besser, dieses rumgenörgel wegen Scriptfehlern und das dies die Server zu sehr belastet nervt mich... mehr als 1 Fehler im Apache Log = Scripte sind schlecht und machen Alles kaputt..

Kann Jemand relevante Fehler in diesem Logfile sehen?

Die Frage ob Webserver oder Datenbank die Platte belastet kann er nicht beantworten solange ich sooooo viele Fehler in den Skripten habe....
Sind 40 Meldungen in 40 Minuten wirklich so viele Einträge?

By the way... ich habe 30 Euro Paket (nicht ein 3 Euro Paket) mit SDD bestellt und bisher auch bezahlt.
Die Scripte generieren Statistiken, der User bekommt nur fertige Berechnungen ausgeliefert aus der DB... 120 Sekunden Timeout muss ich für Datenaufbereitung lassen oder die Berechnung der Statistiken in gaaaanz kleine Portionen stückeln und dann wieder Organisation erstellen damit diese kleinen Portionen nacheinander abgearbeitet werden... es sind teilweise 1 Mio Verkaufe deren Durchschnittswerte berechnet werden - pro Qualität, Jahr, Land, Handler / Auktion usw. der Server generiert bis zu 6000 Durchschnittspreise plus Grafiken für eine Münze... das dauert halt bisschen auf kleinem Server....


Update:
1. Mail vom Provider
Guten Tag Herr XXXXXX,

Der Server wurde wieder eingeschaltet und Sie müssen bitte dafür sorgen, daß GAR KEINE Script-Fehler mehr vorhanden ist!
Auch das Aufblähen der max executing- Time auf 120 Sekunden (als Dauereinstellung), ist ganz und gar nicht gut! Normal sind
30 Sekunden, danach sollte jedes Script fertig sein, wenn nicht, liegen andere Probleme vor! Bei einem größeren Update z.B.
kann man mal die 30 Sekunden erhöhen, darf dann aber nicht vergessen, diese wieder runter zu setzen!

Auch haben wir Sie bereits in der Vergangenheit darüber informiert, daß Sie Ihre Scripte so umstellen müssen, daß diese auch
mit der neuesten PHP-Version laufen und einwandfrei sind! Sie haben damals einen Server bestellt mit SATA und werden gehostet
auf NVMe-Systemen, die 800 mal schneller sind als SATA, aber es ist nicht ok, wenn Ihr Server die gesamte Festplattenleistung
(Performance) so schluckt, daß alles andere runter zieht und gestern war das einfach zu extrem!

Die Probleme scheinen auch gestern insbesondere immer in eime Funktionsbereich translate aufgefallen zu sein!

2. Mail
Der Server wurde wieder eingeschaltet, um die Probleme unverzüglich zu beseitigen!
Script-Fehler dürfen keine entstehen, ansonsten müssen die Scripte so überarbeitet werden, daß diese
keine Fehler erzeugen! Nur danach kann man dann weiter prüfen, wo optimiert werden muß!
In welchem Bereich der Disk-Speicher so hart belastet wird, können wir nur analyiseren, wenn Ihr System
stabil läuft und keine Fehler verursacht! Die Vermutung liegt nahe, daß dies durch PHP/MySQL-Scripte
erfolgt.

Dazu gehört auch, daß MySQL-Abfragen im Slow-Log geloggt werden, die länger benötigen als 3 Sekunden!
Diese müssen dann optimiert werden!
 
Erster Eindruck über Schreibart und Inhalt: unprofessioneller Anbieter. Meine Empfehlung: ASAP weg da!
Ob deine Skripte tatsächlich Probleme machen ist schwer zu beurteilen, aus den imho pampigen Antworten des Supports ist das aber auch nicht herausfindbar. Meines Erachtens ist es bei Managed ein (grosser) Teil der Dienstleistung dass man zuminest eine preliminäre Diagnose der möglichen Fehlerquelle durchführt.

Wenn du managed willst, kann ich u.a. PHP-Friends empfehlen. Hetzner ist als reiner Serveranbieter sehr gut aber managed waren sie zumindest längerfristig auch nicht sonderlich tolle, hat sich aber eventuell gebessert...

Er belastet das Disk-Array im Terrabyte - Bereich
Click to expand...
Die vom Anbieter anfangs angegebene Probleme bezieht sich meines Erachtens bei diesen Angaben nicht auf die Transferbelastung (IO) sondern die Kapazitätsbelegung durch die entstandenen Logs. Ich würde mal die Logs schlicht auf error-only stellen lassen oder ganz abschalten und dann die Logdateien entfernen lassen.
Allerdings hast du einen dedicated virtual server, was für dedizierte Ressourcen spricht. Wie kann man bei dedizierten Ressourcen mehr als die zugewiesenen Kapazitäten belegen? Hier scheint der Anbieter unklar, untransparent und möglicherweise trügerisch vor zu gehen...

es ist nicht ok, wenn Ihr Server die gesamte Festplattenleistung
(Performance) so schluckt, daß alles andere runter zieht und gestern war das einfach zu extrem!
Click to expand...
Aha die zweite Email spricht plötzlich von der Transferlast. Hmm, ob hier wohl gar nicht die Logdateien sondern die Datenbank die Ursache ist, insbesondere bei der Funktionsbeschreibung des Codes. Das sollte für jeden Anbieter aber auf den ersten Blick erkennbar sein. Ob der Anbieter schon mal was von resource throttling gehört hat?

Der Server wurde wieder eingeschaltet und Sie müssen bitte dafür sorgen, daß GAR KEINE Script-Fehler mehr vorhanden ist!
Click to expand...
Das nenn ich mal eine Aussage... eine Aussage wo meine Antwort wäre "leck mich doch sonstwo"....
Beispiel: "ap_pass_brigade failed in handle_request_ipc function" aus der Log ist kein Skriptfehler sonder Verbindungsabbruch des Clients.


Anmerkung: Eventuell wäre es sinnvoll die Wertberechnung cron-basierend durch zu führen oder Zwischenwerte für vergangene Perioden zu speichern damit die Berechnung schneller erfolgt. Das ist aber Optimierung und und nicht Fehlerquelle. Bei Cronjob wird ein schlechter Anbieter dann über eine konstante Ressourcenbelastung meckern.... Der Anbieter beschwert sich aber vermutlich um deine Datenbankbelastung und nicht die Logs, damit wäre es eine sinnvolle Verbesserung.

Der Server wurde wieder eingeschaltet und Sie müssen bitte dafür sorgen, daß GAR KEINE Script-Fehler mehr vorhanden ist!
Click to expand...
:eek: Frag mal was für Drogen die nehmen. Oder lieber nicht...

Sie haben damals einen Server bestellt mit SATA und werden gehostet auf NVMe-Systemen, die 800 mal schneller sind als SATA
Click to expand...
Im besten Fall bietet NVME die 4fache Geschwindigkeit zu SATA bei sequentieller Last...

Auch das Aufblähen der max executing- Time auf 120 Sekunden (als Dauereinstellung), ist ganz und gar nicht gut!
Click to expand...
Mit was für einer Begründung kommt dieser Schwachsinn denn jetzt? Schon allein Wordpress's Anacron Updater braucht mehr als 30 Sekunden in den meisten Fällen.

Und dann wundert man sich als Mitarbeiter eines Webhoster dass die Kunden alle Aussagen in Frage stellen wenn man solche Mitbewerber auf dem Markt hat.
 
Die Art und Weise, wie der Support hier mit seinem Kunden umspringt, kommt mir seltsam bekannt vor.
Derart unqualifizierte und völlig weltfremde Argumentationen riechen nach HEG :eek::cool:

d4f said:
Erster Eindruck über Schreibart und Inhalt: unprofessioneller Anbieter. Meine Empfehlung: ASAP weg da!
Click to expand...
Die einzig sinnvolle Option!

d4f said:
Wenn du managed willst, kann ich u.a. PHP-Friends empfehlen.
Click to expand...
Der Empfehlung kann ich mich nur anschließen (alternativ...weiter gute Hoster hab ich in meiner Forensignatur verlinkt).

Der Wechsel zu einem "kleineren" Anbieter hat auch enorme Vorteile. Der Anbieter ist viel näher am Kunden dran und kann viel besser auf die Wünsche und Bedürfnisse eingehen als ein Massenhoster, der nur Produkte von der Stange liefert.
Dafür sind die nicht ganz so großen Hoster vielleicht etwas teurer...Aber die paar Euro mehr machen den individuellen Service auf jeden Fall wett.
 
Wenn der Support solche Aussagen bringt, bezweifle ich, dass dort wirklich technisches Verständnis vorhanden ist.
Wenn dann mal wirklich Probleme auftauchen, wirst Du vermutlich Probleme haben, brauchbare Hilfe zu bekommen.

Ich würde den Hoster wechseln.
 
Wobei ein paar Dinge von dem, was der Support da schreibt durchaus bedenkenswert sind - GET Abfragen, die regulär von Usern getriggert werden und Laufzeiten von > 120s benötigen klingt nach "Broken by Design" - und Scriptanpassungen, daß diese zumindest Code-technisch fehlerfrei durchlaufen mit akutellen PHP-Versionen sind jetzt auch nicht weltfremde Forderungen.

Derlei Dinge werfe ich "meinen Entwicklern" auch um die Ohren wenn die entsprechendes abliefern.

... das Frontend sollte idealeweise flott und lastarm laufen, entsprechend aggregierte Daten kann man ja problemlos via Backend-Scripte generieren und bereitstellen.

Sprich - auch wenn's läuft sollte sich der TE da massive Gedanken über Anpassungen in der Applikations-Struktur und der Datenhaltung machen.
 
Danke für die Hinweise - ich denke ich muss mir einen Provider suchen...

@marce
ich möchte nicht behaupten das meine scripte toll sind... aber frontend ist von der datengenerierung getrennt - solange es suchvorgänge und auswertungen sind die zumindest 2 mal im monat vorkommen.... spezielle auswertungen < 2 mal wird bei useranfrage generiert und danach abgespeichert (cache)
ich denke 98% - 99% der anfragen werden über cache beantwortet.

fehler im logfile letzte 20 minuten 13 (2 notes variable nicht vorhanden, andere einträge kann ich nicht so einfach ändern)

ich habe ihn noch einmal gefragt was den traffic verursacht... hier mal seine antwort:


Guten Tag Herr XXXXXXXXXX,

Sie haben die Probleme überhaupt nicht abgestellt - Es sind Script-Fehler:

[Tue Apr 30 11:18:45.851529 2019] [fcgid:warn] [pid 6259] [client 111.68.48.58:54388] mod_fcgid: stderr: PHP Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in
/var/www/vhosts/muenzenwert.de/httpdocs/Database/dbConnect.php on line 5, referer: https://www.muenzenwert.de/UI/su.php

ERNEUT:

Alle Versionen PHP < 7.1 sind gefährlich und werden NICHT MEHR gewartet! Diese werden weiterhin von Hackern maletriert!

Das Script z.B. daß diese Fehlermeldung abgesetzt hat, ist umzustellen auf mysqli statt mysql! Das diese Scripte umzustellen sind, wurde von den PHP-Entwicklern bereits seit ÜBER 10 Jahren bekannt gegeben!

PHP 5.6 wird zum Sicherheitsrisiko - Heise-Artikel vom 15.12.2018

https://www.heise.de/newsticker/meldung/PHP-5-6-wird-zum-Sicherheitsrisiko-4191009.html

Sie können über Plesk bei der Domain die Log-Files abrufen, dort sortieren "ältere zuerst" und nur Fehler und den Zustand auch nach einer Anpassung prüfen!
Es dürfen keine Fehler mehr geloggt werden und Sie sollten danach dringend auf php 7.1 umswitchen! Wir helfen Ihnen beim Umswitchen und empfehlen Ihnen vorher
von folgenden Seiten unter der Domain Screen-Shots anzufertigen, bevor Sie umswitchen:

a) Webhosting-Zugang
b) Hosting-Einstellungen
c) Einstellungen von Apache & Nginx
d) PHP-Einstellungen

Aber nochmal, um das ganz deutlich zu sagen: Vor dem Umswitchen auf php7.1 müssen Sie alle Fehler, die zu Fehlermeldungen bisher führen, beseitigt haben,
da sonst Ihre Websites gar nicht mehr laufen werden!

Die Argumentation es werden 10.000.000 berechnet, kann ich nicht nachvollziehen, weil entweder kann man das ganze cachen oder so verwalten, daß nicht diese Last entsteht ODER Sie benötigen einen dedizierten Server mit NVMe-Disks, der dann ab ca. 100 Euro / Monat kostet! Natürlich kann man das auch auf 2 Server verteilen, würde dann doppelt so viel Kosten verursachen! Also sollte Sie doch erst
einmal da anfangen, wo die Fehler liegen, nämlich in schlecht oder veralteten programmierten Scripts!

Auch wussten Sie doch bereits von den Problemen, wir haben Sie doch schon paar mal darauf hin gewiesen!

Für weitere Fragen stehen wir Ihnen jederzeit zur Verfügung.

------------------------------------------------------------------------------------------------------------------------------

-> ich habe ihn nun noch einmal per mail gefragt wo denn der traffic entsteht und ob wir nun über PHP Versionen sprechen wollen oder ein problem mit den daten mengen haben die auf eine festplatte geschrieben werden....
 
Kann es sein, dass du einen ausländischen Hoster hast, bei deren Support keine deutschsprachigen Mitarbeiter beschäftigt sind?
Eine konkrete Analyse diner Server- und Softwareprobleme kann ich nicht ersehen aus dem Mail.
Was allerdings in deinem Managed-Support beinhaltet ist, ist mir unbekannt.

Dass es keine Fehler mehr im Logfile geben darf ist Unfug, solche Meldungen gibt es immer mal wieder.
Wie deine Skripte performant bei SQL sind kann ich nicht sagen, das weit du wohl eher.
Und ob dein SQL-Server optimal gecacht wird auch nicht.
Welche PHP-Versionen nicht mehr gewartet werden ist auf https://www.php.net/eol.php zu sehen. Veraltete PHP/deren Module weisen je nache version Sicherheits- und Performanceprobleme auf.
 
Also...mit dem Wechsel auf mysqli hat er zum Teil recht. Aber noch wird mysql unterstützt und "nur" als deprecated informell geloggt.

Muenzenwert said:
Alle Versionen PHP < 7.1 sind gefährlich und werden NICHT MEHR gewartet!
Click to expand...
Das ist (abhängig von der verwendeten Distribution) völliger Bullshit!
Debian Stretch hat z.B. PHP in der Version 7.0 im Einsatz und natürlich werden Patches und Fixes auch in dieser Version eingepflegt.

Muenzenwert said:
Diese werden weiterhin von Hackern maletriert!
Click to expand...
:eek:o_ODer meinte sicherlich malträtiert:cool:

Muenzenwert said:
Vor dem Umswitchen auf php7.1 müssen Sie alle Fehler, die zu Fehlermeldungen bisher führen, beseitigt haben,
da sonst Ihre Websites gar nicht mehr laufen werden!
Click to expand...
Auch das ist völliger Blödsinn!
Mit Sicherheit werden Anpassungen erforderlich sein, aber die Webseite ansich dürfte trotzdem erstmal abrufbar sein (wenn auch möglicherweise mit Fehlermeldungen)
 
Wobei allein schon die Tatsache, daß man eine php-Version in irgendeinem Backend einfach so wechseln kann schon andeutet, daß da wohl nicht die (mehr oder weniger gut gepflegten) Versionen genommen werden, die das jeweilige OS bietet.

... und ob eine auf php 5.6 entwickelte Seite mit php 7.x läuft hängt erst mal von den Implementierung ab - bzw. wie "gut" der jeweilige Entwickler war.

Von "völlig problemlos" über "die eine oder andere Warning im error-log" bis zu "500er und das war's dann" gibt's da alles.

bzgl. mysqli vs. mysql - mit php 7 hat war's das mit "mysql" - entfernt, keine Warning.
www.php.net

PHP: mysql_connect - Manual

PHP is a popular general-purpose scripting language that powers everything from your blog to the most popular websites in the world.
www.php.net www.php.net
 
@GwenDragon
Firmensitz ist Spanien, Serverfarm in Deutschland..
ich denke ich darf hier die URL posten... https://www.1awww.com/
ich bin zu diesem Anbieter da bei Tests / Serverlisten der Support sehr gelobt wurde und es ein kleiner Anbieter ist. Für 30 Euro im Monat kann man vermutlich bei vielen anbietern 50GB HD und 8GB Ram bekommen..
Die Mails kommen vom Inhaber selbst..

Scripte optimieren und PHP upgraden muss ich sicher einmal machen, für mich hatte Projektaufbau Prio da ich davon leben muss... schöne Scripte ohne Besucher helfen wenig.... Besucher mit Einnahmen und paar Einträge im Log kann ich mit leben...

Managed Server ist vor allem Updates Serverbezogen, sich um den Server an sich nicht kümmern müssen
 
Wobei man in der ganzen Sache grundsätzlich anmerken sollte, daß ein Anbieterwechsel allein nicht alle Probleme lösen wird.
Um die Scriptanpassungen wirst du letztendlich trotzdem nicht herumkommen, weil PHP v5.x auch bei anderen Anbietern kaum bis garnicht mehr unterstützt werden wird.

Wenn du deine Shopsoftware nicht selbst geschrieben hast, wird die Software aktuell noch gepflegt und weiterentwickelt bzw. mit Updates versorgt?
 
@marce
PHP 7.x wäre sicher nicht schlecht, ich denke es wird mich 1-3 Wochen kosten diese Umstellungen zu machen.. ein bisschen Struktur habe ich in den Programmen schon..

ABER: Diese Programme wurden ca. seit 4-6 Monaten nicht mehr geändert, ich habe mich vor allem um bessere Bilder, Texte usw. gekümmert und Mitarbeiter geschult. Die Scripte können nicht der Grund sein weshalb gestern Terrabytes an Daten auf eine Festplatte innerhalb von 10 Minuten geschrieben wurden..

Das muss einen anderen Grund haben - aber ich habe nach wie vor keine Idee an welcher Stelle das passieren kann.
PHP alte Version könnte Hacker genutzt haben, die Frage ist wie ein Hacker Plattenzugriffe in diesem Umfang generieren kann, falls es einer war...

DB Auslagerungsdatei hat zumindest nichts geschrieben seit Server wieder online ist, DB Cache scheint alles im Speicher beantworten zu können.
Platten-Auslastung liegt immer noch bei 10GB wie es normal ist.. große Files wurden nicht erzeugt.


@nexus:
Es ist keine Shopsoftware, es ist eine selbst geschriebene Anwendung in PHP
Ja ich muss umstellen, steht dieses Jahr auch auf dem Plan...
Zuerst werde ich das Problem mit der Plattenbelastung finden müssen, sonst ist Server bald wieder down... eine Umstellung nun auf 7.x bringt da denke ich nichts, genauso wenig wie eine Bereinigung der Scripte um keine Warnings mehr im Logfile PHP zu haben... ich bin mir recht sicher 10 Warnings pro Stunde können keine solchen Datenmengen auf einer Festplatte verursachen.



Status letzte Stunde:
User gleichzeitig Online ca. 80
Logfile 14 Einträge (10x broken pipe / 2x ModSecurity warning / 2x PHP Notice: Undefined variable)
DB Auslagerung keine
DB Netswerkverkehr ca. 25MBit Durchschnitt, max 56MBit
DB Anfragen knapp 4k
CPU Auslastung ca. 1.2%
Ram Auslastung 54%

Im Moment scheint Server normal zu laufen, wie viele Daten auf die Festplatte geschrieben oder gelesen wird - keine Ahnung..

Jemand eine Idee was ich schauen könnte um zu sehen was oder wo so viele Daten auf die Festplatte geschrieben werden?
Scripte greifen nicht auf HD zu, nur auf die DB
 
Last edited:
Alle Versionen PHP < 7.1 sind gefährlich und werden NICHT MEHR gewartet!
Click to expand...
Nur weil der Hersteller sie nicht mehr wartet heisst nicht dass sie nicht wartbar sind. Sowohl Distros als auch Drittanbieter bieten Security-Patches für ältere PHP-Versionen. Der Anbieter meines Vertrauens, Cloudlinux, aktuell bis hinunter auf die 14 Jahre alte PHP Version 4.4!

Alle Versionen PHP < 7.1 sind gefährlich und werden NICHT MEHR gewartet! Diese werden weiterhin von Hackern maletriert!
Click to expand...
Aktuell gibt es auf den ersten Blick keine bekannten im Webhosting kritischen Sicherheitslücken in PHP 5.6 ausser man verwendet die Exif-Funktionen.
Man sollte die Version natürlich trotzdem nicht mehr verwenden wenn man keine Security-Updates kriegt aber mit dieser Panikmache glaubt man ja schon fast dass der Support-Mitarbeiter ehemals bei McAffee oder Symantec gearbeitet hat...
Auch heise, ehemals das go-to Medium für relevante deutsche IT-Nachrichten ist seit Jahren auf dem besten Weg richtung Bild-Qualität.
https://www.cvedetails.com/vulnerab...t_id-128/version_id-167754/PHP-PHP-5.6.0.html

Das Script z.B. daß diese Fehlermeldung abgesetzt hat, ist umzustellen auf mysqli statt mysql!
Click to expand...
Quick & dirty Trick dazu: https://github.com/mattbit/mysql-compat

Mit Sicherheit werden Anpassungen erforderlich sein, aber die Webseite ansich dürfte trotzdem erstmal abrufbar sein (wenn auch möglicherweise mit Fehlermeldungen)
Click to expand...
Aus Erfahrung knallt es öfter als es nicht knallt =) Aber man kann ja zurückschalten bis man es debuggt hat.

ich denke ich darf hier die URL posten...
Click to expand...
Ohne den Anbieter bashen zu wollen, ein Schnelltest über whatcms.org ergibt Joomla 3.4 was von 2015 ist. Die aktuelle Joomla3.x Version ist 3.9.x und beinhaltete mehrere Securityfixes seit 3.4...... wie war das nochmal mit neuster Version?


NB: Laut aktuellem AGB des Anbieters ist bei virtuellen dedizierten Server nur das Drosseln aber nicht das Sperren des Servers erlaubt solange kein Hardwareschaden entsteht. Da aktuelle Serverkomponentne für 3Jahre Dauerbetrieb in Rechenzentren ausgelegt sind sowie basierend auf einschlägigen Tests kann durch CPU- oder SSD-Schreibbelastung nicht von Schaden ausgegangen werden.
 
You must log in or register to reply here.
Back
Top