Filesystem storage, many small (mail) files, performance impact


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 :slight_smile:
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.

Thank you !

1 Like

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 :smiling_face:
The file attachment are stored on the filesystem in my package installation.

The recursive change owner is enforced by (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.


Thank you @MrGeneration for this workaround to the chown -R downside, good news :+1:

Do you perhaps have any idea regarding the main concern of this topic, the email files ?
Thank you again !

1 Like

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.

That’s all I can share to the topic sorry.