wir nutzen sei Februar 2022 (4 Monate) in SuiteCRM folgende Module:
Accounts: ca. 3.000 Einträge
Opps: ca. 600 Einträge
(eigene Tabelle): ca. 300 Einträge
Keine Dokumente, keine Bilder oder sonstige.
Der benötigte Speicherplatz explodiert förmlich. Mittlerweile sind 47 GB auf dem Laufwerk belegt. Das kann doch unmöglich von den bisschen Daten kommen.
Logfiles habe ich schon gecheckt und auch gelöscht, aber das war nur ein Tropfen auf dem heissen Stein.
Ich habe schon in Deutsch und Englisch gegoogelt aber nichts passendes gefunden.
Hat von euch irgendjemand einen Tip oder Ansatz woran das liegen könnte?
V 7.11.18 (war aber davor auch schon) beobachte das seit Beginn.
habe ende Februar bereits 40GB weiteren Speicherplatz hinzugefügt und bin jetzt echt überrascht, dass dieser schon wieder aufgebraucht ist.
Moin.
Ich glaube auch nicht, dass die SuiteCRM-Daten den Platz verbrauchen. Du muss rausfinden, was den Platz verbraucht. Ich würde mit ‘sudo du -s *’ vom Wurzelverzeichnis absteigen und suche, wo das Übel liegt.
L.
Mit Lars’ Befehl prüfst du die Größe des Dateisystems, interessant wäre aber auch die Größe der DB/der Tabellen. Insofern du mit Workflows gearbeitet hast: hast du hier mal geprüft, ob die Jobs zu oft laufen? Laufen ansonsten Emailimporte über überwachte Postfächer?
das war schon mal ein sehr guter Tip. Habe herausgefunden, dass im home/default/html (also in der CRM Installation) nur 813 MB liegen. D.h. irgendwas ballert mir den Speicherplatz voll.
Kannst du mal den Count von den aow-Tabellen abfragen (ich meine select count(*) from aow_processed;)?
oder gleich so was:
SELECT table_name AS "Table",
ROUND(((data_length + index_length) / 1024 / 1024), 2) AS "Size (MB)"
FROM information_schema.TABLES
WHERE table_schema = "hier-db-namen-einsetzen"
ORDER BY (data_length + index_length) DESC;
ich schaffe es leider nicht eine SQL Abfrage auf die DB zu machen (Portfreigaben habe ich gesetzt).
Könnte aber über das Terminal auf die DB zugreifen…
Hi,
ja, wenn ich mich recht erinnere, ist die aow_processed-Tabelle das Log des Workflow-Moduls. Wenn die Tabelle überläuft, heißt das i.d.R.:
Workflows optimieren: versuchen, möglichste viele nur beim manuellen Speichern auszuführen. Speziell die Workflows, die auch vom Scheduler/Cron ausgeführt werden, laufen theoretisch pro Minute einmal pro Datensatz (je nach Filter etc.). Das kann aber schon eine ganze Menge sein.
Workflows auf einmalige Ausführung reduzieren
Workflows ersetzen durch Hooks: WFs sind gut, um kleinere Automatismen im System abzubilden, für komplexere Abläufe würde ich grundsätzlich eher zu Hooks greifen (du hast genau im Griff was passiert, bist wesentlicher freier in der Gestaltung und kannst auch das Logging selbst übernehmen).
Noch ein wichtiger Hinweis: Manche Workflows sollen nur einmalig pro Datensatz laufen (Checkbox im WF). Diese Prüfung wird imho auch über die aow_processed-Tabelle abgebildet, d.h. dort einfach alles zu löschen könnte unangenehme Effekte haben.
Hey, vielen Dank.
nachdem ich jetzt die beiden Verursacher entdeckt habe, konnte ich im Forum ein paar Threats dazu finden. Stehe offensichtlich nicht alleine mit dem Problem dar.
Verständnisfrage: hooks werden nur ausgeführt und nicht in Tabellen gespeichert?
d.h. ich müsste für (fast) alle WF die ich einsetzte hooks schreiben.
oh, ich glaube das übersteigt aktuell meinen Wissensstand. einen hook habe ich schon mal nach Anleitung umgesetzt, vielleicht finde ich gute tutorials im Web.
ich habe eine spiegelung der installation laufen. ich versuche mal dort was passiert, wenn ich die tabelleneinträge lösche …
Hi,
ja, mach das mal. Kopie vom System ziehen und dort experimentieren ist immer eine gute Wahl (auch bei Upgrades).
Meine Warnung ist auch ein Randfall, ob die wirklich greift hängt vom Inhalt deiner WFs ab.
Verständnisfrage: hooks werden nur ausgeführt und nicht in Tabellen gespeichert?
genau, mit Hooks werden eventbasiert von dir definierte Methoden ausgeführt. Ob dort etwas geloggt wird, hängt von deinem Code ab. Dort kannst du auch entsprechende Filter und wenn-dann-Regeln implementieren, denn Hooks werden letztlich komplett in PHP geschrieben. Hooks sind aber gut dokumentiert:
und bei konkreten Fragen kannst du ja hier posten.
Bevor du aber sofort deine IDE startest: versuch mal die Ausführungen der WFs zu reduzieren. Die Menge der Daten lässt schon vermuten, dass dort einiges viel zu oft und unnötig ausgeführt wird.
Function field: ein solches Feld ist nicht auf DB-Ebene vorhanden, es führt zur Laufzeit Code aus und zeigt das Ergebnis als Feldinhalt an (Code wäre also: “hole den Account zu dieser Opp. und gib den Ortsnamen zurück”. Nachteil: solche Felder lassen sich beispielsweise nicht im Reporting einsetzen. Vorteil: keine Verletzung der Normalisierung (“keine Info redundant speichern”).
Kopieren per WF: vllt. kannst du über Konditionen eingrenzen, wie oft der WF ausgeführt wird (prüfst du bspw., ob die Opp. schon einen Ortsnamen hat? Falls ja, könnte der WF abbrechen).
Umbau als Hook
Mehr fällt mir spontan aber nicht ein
E: du könntest das Kopieren des Ortsnamens natürlich auch als Scheduler machen, der alle paar Stunden läuft. Die Schritte wären übersichtlich:
suche alle Opps ohne Ortsnamen
pro gefundener Opp: Suche den Ortsnamen des zugehörigen Accounts und aktualisiere die Opp-Bean
Das wäre charmant, da der Scheduler nur so oft ausgeführt wird wie konfiguriert (benutzt reguläre crontab-Notation), aber die Nutzer würden nicht unmittelbar den Ortsnamen sehen sondern verzögert. In Summe klingt daher eine eventbasierte Lösung sinnvoller.
ich habe eine Vermutung, welcher WF hier der Übeltäter ist.
Im Modul Opp habe ich ein Feld “Ort” angelegt und lasse mir per WF beim speichern der Opp immer den Wert aus “account.billing.city” übertragen.
Bist Du sicher? - Wie viele % Records sind nur das ?
Wie Oft pro Tag ist eine Opp veraendert?
Wie oft… ist die ‘Ort’ Feld in Opp veraendert?
Es kann nur sehr wenig solche Events sein, oder?..
