Expected behavior:
When choosing filesystem storage, received emails should be proceeded and stored into database, attached files should be stored on filesystem.
Actual behavior:
Received emails are (IMO) wrongly stored both in database and on filesystem.
Attached files are properly stored on filesystem only.
More exactly, the complete raw email (headers + body) is stored on filesystem.
What is stored in database is the body “only”.
Steps to reproduce the behavior:
Enable filesystem storage, and look at stored files. Emails should not be stored on filesystem, as they are already stored in database. Note that emails sent by the triggers are also stored on the filesystem…
Impact :
Storing emails on filesystem leads to many many small files.
Filesystems generally do not like managing lots of small files, leading to global performance impact when the number of small files increases.
And on a Zammad instance with a fair amount of new tickets per day, the number of small files increases… a lot
Zammad will then certainly have the best performance results using / grabbing mails from database rather than from filesystem.
Another downside effect is the Zammad update process which takes longer every time (hours now here), due to the following command burning the filesystem : chown -R zammad:zammad /opt/zammad
Question :
My question is not about the performance part (I’m used to performance analysis).
But rather why Zammad stores these email files.
Proposal :
The raw email content, if needed, could be stored, as text (an email is text…), in the database.
Could be an option, with an ability to migrate (as for the files themselves).
Will for sure lead to some performance improvement.
In my case the update process needs 45 minutes with over 50.000 tickets. The update process is every time longer because more and more tickets exists to that time (by 4 cores, 16GB RAM).
Maybe here is a way to optimize that
The file attachment are stored on the filesystem in my package installation.
Thanks
The recursive change owner is enforced by packager.io (our package packager) which we cannot turn off.
There were attempts on their Github repo to do so, but I believe it had no outcome.
What you can do is this before moving storage to filesystem (or move away your data first):
stop Zammad
create or move Zammads storage/ directory to a for you fitting location
warning: You’re responsible that these files are readable and writable by the zammad user.
create a symlink in /opt/zammad/ e.g. like so: cd /opt/zammad/; ln -s /path/to/your/storage/folder storage
start Zammad
This is officially supported by Zammads backup script since roughly 3 weeks thanks to a community user. It also is update safe and will save said folder from being change ownered and should reduce the update process to anything in between 3-10 minutes. Depending on your hardware etc etc.
I can’t really say much to that topic.
What I can say is that we have instances with over 2 million articles which translates in a huge bunch of single files.
I don’t see a connection in terms of slowed performance in regard to a growing instance size.
What performance degrades usually is bad or no performance tuning, not enough resources or troublesome configuration in Zammad.
