Hi,
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.
Ja, ich arbeite auch mit Workflows. mehrere laufen immer aktiv permanent im Hintergrund.
Email nutze ich nur den SMTP um Reports zu versenden.
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;
src: https://www.a2hosting.com/kb/developer-corner/mysql/determining-the-size-of-mysql-databases-and-tables#:~:text=To%20check%20the%20sizes%20of%20all%20of%20your%20databases%2C%20at,(MB)%22%20FROM%20information_schema.
Der Tipp von diligent ist auch gut. Gucken, ob irgendwelche Tabellen sehr groß sind job_log o.ä. - geht zb gut mit phpMyAdmin.
Schon jetzt einmal ein ganze grosses Dankeschön an euch beide. Ich komme der Sache näher.
In der SQL DB liegen 39GB
Weitere Analysen zeigen direkt 2 grosse Files.
- Frage: hängen die mit den Workflows zusammen (Processed…)
- Frage: kann man die Löschen/verkleinern/komprimieren?
Danke
Nic
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…
vom Terminal aus geht es
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.
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.
entweder löse ich das mit einen hook oder es gibt eine viel einfachere möglichkeit die Info in den Opps anzeigen zu lassen… die mir nicht bekannt ist
Hi,
ja, gibt verschiedene Möglichkeiten:
- 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.
(Warnung: Meine Deutsche is schrecklich)
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?..
Kannst Du die detaile von dem WF hier kopieren -
if you prefer, we can communicate in englisch.
an opp will maybe changed once a week.
the field “Ort” will be copied every time on save.
First of all, thanks to all of you who supported me on this issue.
@crmspace @DJuser @larsschaps
I found a temporary solution to reduce the size of data w/o destroying my DB. I guess I have to repeat this once a month as long the the long term solutioin (see below) is not setup.
The following sql was copied from the web and modified a little bit, so it suites for me.
For everybody who faces the same issue, pls be aware that dropping tables can destroy your DB if you not exactly know what you are doing!
Situation before:
then doing sql (line by line). you can adjust the interval for your needs.
CREATE TABLE default_grgq1.aow_processed_new AS SELECT FROM default_grgq1.aow_processed WHERE date_entered >=curdate()-interval 1 day;
ALTER TABLE default_grgq1.aow_processed RENAME default_grgq1.aow_processed_old;
ALTER TABLE default_grgq1.aow_processed_new RENAME default_grgq1.aow_processed;
DROP TABLE default_grgq1.aow_processed_old;
CREATE TABLE default_grgq1.aow_processed_aow_actions_new AS SELECT FROM default_grgq1.aow_processed_aow_actions WHERE date_modified >=curdate()-interval 1 day;
ALTER TABLE default_grgq1.aow_processed_aow_actions RENAME default_grgq1.aow_processed_aow_actions_old;
ALTER TABLE default_grgq1.aow_processed_aow_actions_new RENAME default_grgq1.aow_processed_aow_actions;
DROP TABLE default_grgq1.aow_processed_aow_actions_old;
Situation after:
Finaly the long term solution for me would be to get rid off the WFs (or change the frequency) and use logic hooks if possible.
1 Like
Have a look at this
Do your Worfklows require the “Repeated runs” unchecked? That’s what is making them store all those rows. And if they do require it, when you move the rows elsewhere you’re affecting that requirement.
Often you can make them allow “Repeated runs” and then create some limit to execution through conditions (check some field inside the record, for example). That is the real long-term solution.
pgr is right - your Workflow is doing something WRONG.
Solve that, and your logs will be fine.
At least, you wrote that you Opp’s are changing not very much:
an opp will maybe changed once a week.
the field “Ort” will be copied every time on save.
because, you team are not saving that many Opps per-day? Dozens? Hundreds?
You wrote:
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.
why do you think that specific WF is the problem?
Let’s get some more evidence
BEFORE your clean-up script above is run - run these SQL queries:
A) The total quantity of records are being added , per day, to the table
- select count(*) from aow_processed where date_modified > ‘2022-05-22’; use yesterdays date - not 22 May when you run this
B) How many from that ONE workflow:
select count(*) from aow_processed where date_modified > ‘2022-05-22’ AND aow_workflow_id=‘put-the-workflow-id-here’;
If the % is very high from just that 1 WF:
Next thing to check: Look at the time-of-day
select date_modified, aow_workflow_id, parent_id from aow_processed where date_modified > ‘2022-05-22’ AND aow_workflow_id=‘put-the-workflow-id-here’ order by date_modified;
If you see
- MANY entries when your office is empty
OR
- hundreds or entries per minute:
then something else is processing and saving many opps -and each save triggers the Workflow above.
Maybe it is a DIFFERENT workflow, that you run on the Opps, every night?
… - or a script or a logic-hook or code: anything that is editing and saving MANY opportunities very quickly, within SuiteCRM code. (anything that is doing a raw SQL query against the database will NOT cause this, because that will NOT cause the workflow to be triggered)
Without more evidence, it’s hard to advice.
But the root cause here is NOT that Workflows in general cause big databases.
It is something else - 99% sure.
Find that, and the SQL table creating/dropping can be errrrr dropped!