Antworten:
Guten Tag. 1. Die Auslastung der CPU kann mehr als 100 % betragen. Dies bedeutet, dass die pro Sekunde zu erledigenden Aufgaben X% mehr sind, als der Prozessor bewältigen kann. Wenn der Prozessor auf dem Server beispielsweise 1000 Tasks pro Sekunde ausführen kann und sich 1500 in der Warteschlange befinden, haben Sie in diesem Moment eine CPU-Last von 150 %. Es ist direkt stark-stark zu vereinfachen. 2. Höchstwahrscheinlich wird gerade eine ressourcenintensive Aufgabe auf dem Server ausgeführt. Wenn Sie eine Produktversion - os haben, können wir die Last zum angegebenen Zeitpunkt analysieren und Ratschläge geben, wie damit umzugehen ist. Die Fertigstellung dauert etwa 3 Stunden.
27.02.2023, 13:15
Originalkommentar zur Version verfügbar: ru
1. Und irgendwie ist es möglich, zumindest theoretisch zu verstehen, was für eine Art von Aufgabe es sein könnte (wenn solche offensichtlichen, komplexen Aufgaben nicht präsentiert würden), dh gibt es solche Aufgaben, die das System regelmäßig einmal am Tag ausführt, das heißt, alle Systemaufgaben? 2. Wenn ich auf dem Server durch den TOP-Befehl zeige, dass der Prozessor die Datenbank lädt, ist es möglich, irgendwie zu verstehen, was das sein könnte (mit welcher Art von Task oder mit welcher Datenbanktabelle arbeitet der Prozessor)?
27.02.2023, 13:27
Originalkommentar zur Version verfügbar: ua
Standardmäßig hat das System keine komplexen Prozesse, die das System so belasten, es gibt Aufgaben zum Übertragen von Aufgaben, TTN-Tracking und andere Aufgaben einmal am Tag/zu einer bestimmten Uhrzeit, aber sie können den Prozessor nicht so belasten. Ja, Sie müssen gleichzeitig sehen, welche schweren Anfragen in der Datenbank hängen, Sie können sie verwenden, um zu verstehen, welches Modul sie macht, und weitermachen.
27.02.2023, 13:29
Originalkommentar zur Version verfügbar: ua
in der Datenbank selbst zum Zeitpunkt des Ladens, in den Protokollen schwerer Abfragen in der Melon-Datenbank. Genaueres kann ich dir leider nicht sagen, da ich keine Datenbankverwaltung und das Abfangen von Lastursachen lehre.
27.02.2023, 13:44
Originalkommentar zur Version verfügbar: ru
1. Ist es normal (laut Screenshot), dass die Last nur auf dem Prozessor zunimmt, aber beispielsweise der Arbeitsspeicher nicht zunimmt? 2. Können einige "Google-Suchroboter" oder ähnliches ähnliche Lasten liefern?
27.02.2023, 15:19
Originalkommentar zur Version verfügbar: ua
Ich füge die Statistiken von phpMyAdmin bei. Laut Statistik 3.275.000 ausgewählte Anfragen pro Stunde. Das heißt, es stellt sich heraus, dass 3.275.000 / 60 = 54583 (pro Minute) / 60 = 909 (pro Sekunde) Es stellt sich heraus, dass es fast 1.000 Anfragen gibt pro Sekunde Irgendwie scheint es zu viel
06.03.2023, 10:23
Originalkommentar zur Version verfügbar: ua
Sie schreiben über "Datensätze" (dh Hinzufügen einer neuen Zeile zur Tabelle) das ist INSERT Und die Statistiken scheinen zu sein "Anfragen" anzeigen, also die Anzahl der SELECTs pro Sekunde. Das sind etwas andere Dinge, meinten Sie, dass Sie 10.000 SELECTs pro Sekunde haben? Es ist nur so, dass es in unserem Fall (es sind ungefähr 3.000 aktive Produkte verfügbar) nicht der Fall ist klar, dass man mit SELECTs so oft auswählen kann, also wir 3.000, und das System macht durchschnittlich 1.000 Anfragen pro Sekunde und das im Laufe von 2-4 Stunden, das heißt, es ist irgendwie unklar, dass das möglich ist 3.000 Produkte mit 3.275.000 Anfragen pro Stunde zu parsen, gleicht eher einer Art DDoS-Angriff
07.03.2023, 10:44
Originalkommentar zur Version verfügbar: ua
Nach einer kleinen Überwachung können Sie sehen, dass periodisch eine Last von 3000-4000 Anfragen pro Sekunde auftritt, dies bei normaler Prozessorleistung, es scheint, dass während der Spitze der Last diese Anfragen jede Sekunde auftreten und dann eine starke Last vorliegt . Nachdem wir uns die Größe der Tabellen angesehen haben, gibt es eine Tabelle mit zusätzlichen Feldern "shopcustomfield", sie hat ungefähr 3.100.000 Datensätze und eine Größe von 1 GB. Vielleicht erzeugt ein solcher Indikator der Tabelle "shopcustomfield" eine solche Anzahl von Anfragen und so weiter Problem, oder sind das ungefähr normale Indikatoren für diese Tabelle?[#$# ]
07.03.2023, 11:04
Originalkommentar zur Version verfügbar: ua
SELECT ist in den meisten Fällen in Bezug auf die Belastung der Datenbank um ein Vielfaches geringer als INSERT, also habe ich Ihnen ein Beispiel mit INSERT gegeben. Diese. Wenn ich 10.000 Inserts mache, kann ich problemlos so viele Reads machen. das ist eine relativ normale Datenmenge, ich sehe deine Grafiken, aber ich kann leider nur sagen, dass sie sehr schön sind, da ist für mich keine wertvolle Information mehr drin. Ja, Sie haben relativ viele Anfragen, bei denen nicht klar ist, wer wann und zu welchem Zweck stellt. Ich habe die Lösungen oben geschrieben, wenn Sie ein Betriebssystem haben (anscheinend ist dies nicht der Fall), geben Sie einen Link zu Ihrer Box und ich werde Ihnen helfen. Wenn Sie mvp haben, liegt das Debuggen von Abfragen an die Datenbank vollständig auf Ihren Schultern.
07.03.2023, 12:55
Originalkommentar zur Version verfügbar: ru
Sie sprechen von 10.000 hinzugefügten Datensätzen, und die Statistiken zeigen 1.000 Anfragen (d. h., eine Anfrage kann beispielsweise 10.000 Datensätze auswählen/hinzufügen/aktualisieren und es werden 1.000 * 10.000 in einer Sekunde sein, diese sind etwas anders Dinge). Versuchen wir zunächst, die Datenbank zu optimieren. Aufgrund der Analyse der Datenbank können wir feststellen, dass es Probleme gibt. Zum Beispiel gibt es in den zusätzlichen Feldern von Prozessprodukten ein Häkchen, das wir verwenden "Automatisch aus dem Produktfilter füllen ." So haben wir zum Beispiel 50 zusätzliche Felder von Prozessprodukten, die wir in einem von 20 Prozessen verwenden, und in anderen nicht. Aber es stellt sich heraus, dass das System auf diesem Häkchen basiert "Automatisch aus dem Produktfilter füllen " füllt die Felder für alle GPs, bei denen Waren hinzugefügt werden, und dadurch erhöht sich die Anzahl der Einträge in der Tabelle um ein Vielfaches, d.h. statt 1 Eintrag werden es 20 (wenn das Produkt allen 20 GPs hinzugefügt wurde). Vielleicht gibt es eine Lösung, wie dieses Kontrollkästchen "Automatisch aus dem Produktfilter füllen" nur für einen bestimmten BP funktioniert, oder vielleicht gibt es eine Aktion im BP, die die Produktfilter in die Prozessprodukte (d.h. die umgekehrte Aktion der Aktion "Produktfilter aus zusätzlichen Prozessfeldern hinzufügen") oder gibt es vielleicht eine Aktion, die zusätzliche Felder von Prozessprodukten entfernen kann?
07.03.2023, 14:01
Originalkommentar zur Version verfügbar: ua
Du verstehst nicht, was ich meine. Bedenken Sie, dass ich Ihnen nichts über die Anzahl der Anfragen geschrieben habe. Du hast an der falschen Stelle angefangen. SIE WISSEN NICHT, WELCHE ANFRAGEN AN DIE DB GEHEN. Aber gleichzeitig fangen Sie an, etwas anzunehmen und einige Tische zu reduzieren, die möglicherweise überhaupt nicht bearbeitet werden. Sie müssen herausfinden: 1. welche Anfragen 2. von wo 3. wie viele an die Datenbank gehen und dann entscheiden, was mit diesen Anfragen geschehen soll. Nicht umgekehrt. Wenn Sie keinen Programmierer / Systemadministrator haben, der diese Analyse durchführen kann, können Sie keine Zeit verschwenden, Sie werden nichts finden. Die Tatsache, dass Sie angefangen haben, in zufällige Tabellen zu stochern und einige Annahmen zu treffen, kann das Problem beheben oder auch nicht, Sie haben ungefähr 300 + - Versuche, einige Tabellen zu "reparieren", sowie die Anzahl der Tabellen. Wirst du alle so anfassen? Ein Freund, all diese 1000 Anfragen pro Sekunde gehen an die novaposhtainvoice-Tabelle und hängen nicht von der Anzahl der Daten dort ab?
07.03.2023, 14:10
Originalkommentar zur Version verfügbar: ru
Die Frage bezieht sich meistens nicht auf das Hauptproblem, ich möchte es nur auch lösen, weil es im Wesentlichen das Volumen der Datenbank und damit den Betrieb betrifft der Server als Ganzes (dh die Datenbank wächst und infolgedessen braucht sie einen besseren Server) Können Sie eine Lösung vorschlagen, um das beschriebene Problem zu lösen?
09.03.2023, 14:57
Originalkommentar zur Version verfügbar: ua
Hinsichtlich der Umstellung sind wir gerade dabei, eine Entscheidung zu treffen (es gibt eine Reihe von Problemen mit der Umstellung, einschließlich der Website).Im Moment gibt es auch keine Lösung für das Betriebssystem, brauchen wir Überarbeitungen vornehmen?
09.03.2023, 15:47
Originalkommentar zur Version verfügbar: ua
Es ist möglich, eine Einstellung vorzunehmen, damit der Wert nicht ausgefüllt wird, wenn er nicht im Filter enthalten ist. Diese. damit es keine leeren Datensätze erzeugt, dauert es ein paar Stunden.
09.03.2023, 16:38
Originalkommentar zur Version verfügbar: ru
Hier geht es nicht um Leerzeichen, sondern darum, dass das System jetzt für alle GPs füllt, denen das Produkt hinzugefügt wird, und wir es zum Beispiel nur für einen GP brauchen
09.03.2023, 16:45
Originalkommentar zur Version verfügbar: ua
[zitieren]
.dev
OneBox Production schrieb:
Ja, gleichzeitig müssen Sie sich ansehen, welche schweren Anfragen in der Datenbank hängen. Sie können sie verwenden, um zu verstehen, welches Modul sie stellt, und weitermachen.
[/zitieren]
Guten Tag
Wir haben in der Datenbank gesehen, dass das System viele Anfragen des folgenden Formats sendet: „SELECT * FROM `novaposhtacontragentcontact` USE INDEX (index_refplatformid) WHERE `counterpartyRef`=........."
Wir haben gesehen, dass das System in den Beispielen Daten zu Kunden auswählt, mit denen sie seit einem Jahr oder länger verbunden sind (das heißt, es wählt einige irrelevante Daten aus, das heißt, es scheint, als würde es alle Daten sortieren).
Unmittelbar nach der Auswahl gibt es Anfragen des folgenden Formats: „UPDATE `novaposhtacontragentcontact` SET `CounterpartyProperty`='Recipient', `Description`= ..."
Und das geschieht regelmäßig.
In wenigen Sekunden werden etwa 12.000 solcher Anfragen gestellt
Dementsprechend wird der Prozessor belastet.
Können Sie mir sagen, warum das System regelmäßig so viele Anfragen nach relativ alten Daten stellt und was man tun kann, um das System daran zu hindern?
14.06.2023, 11:41
Originalkommentar zur Version verfügbar: ua
12.000 Aktualisierungsanfragen für eine Tabelle mit 12.000 Datensätzen führen zu keiner Auslastung.
Dies ist eine Aktualisierung der Liste der Absender/Empfänger der neuen E-Mail.
14.06.2023, 13:32
Originalkommentar zur Version verfügbar: ru
[zitieren]
.dev
OneBox Production schrieb:
12.000 Aktualisierungsanfragen für eine Tabelle mit 12.000 Datensätzen führen zu keiner Auslastung.
Dies ist eine Aktualisierung der Sender-/Empfänger-Gegenparteienliste der neuen E-Mail.
[/zitieren]
Es hängt alles von den Serverparametern + von anderen Lasten ab
Und es stellt sich heraus, dass es noch andere Lasten + diese gibt und infolgedessen hängt alles
Können Sie mir sagen, warum das System alle Datensätze aller Kunden aktualisiert und dies nicht nachts, sondern regelmäßig (vielleicht alle 5 Minuten)?
Aus rationaler Sicht ist das einfach nicht normal (versuchen Sie regelmäßig, die Daten aller Clients zu aktualisieren, zumindest können Sie nur die Clients aktualisieren, bei denen Änderungen stattgefunden haben, und dies nicht so oft und nachts tun).
14.06.2023, 13:48
Originalkommentar zur Version verfügbar: ua
[zitieren]
Julia schrieb:
(vielleicht alle 5 Minuten)
[/zitieren]
ab und zu maximal
[zitieren]
Julia schrieb:
Aus rationaler Sicht ist das einfach nicht normal (versuchen Sie regelmäßig, die Daten aller Clients zu aktualisieren, zumindest können Sie nur die Clients aktualisieren, bei denen Änderungen stattgefunden haben, und dies nicht so oft und nachts tun).
[/zitieren]
Na ja, wenn du das sagst, dann ok. Sie können diese Funktion deaktivieren.
Ich verstehe nicht ganz, was Sie in dieser Situation von mir erwarten? Soweit ich Ihr MVP verstehe, werde ich nicht den geringsten Eingriff in den MVP-Code vornehmen. Wollen Sie damit sagen, dass Ihnen keine Anfragen gefallen? Ok, entferne sie.
Was brauchst du von mir?)
14.06.2023, 15:33
Originalkommentar zur Version verfügbar: ua