Hi OTRS people!
Just a question to clarify our needings for OTRS installation: does anyone know which can be the limit (in term of managed tickets/agents) before the system suffers performance issues?
I mean on a server with 32GB RAM, 32 CPU core, 6Gb/sec SATA HDDs, all standard recommended optimization done (staticDB, TicketIndexing etc etc)
Does anyone have some numbers to give me?
Many thanks
g
OTRS performance limits
Moderator: crythias
-
- Moderator
- Posts: 10170
- Joined: 04 May 2010, 18:38
- Znuny Version: 5.0.x
- Location: SouthWest Florida, USA
- Contact:
Re: OTRS performance limits
How many simultaneous agents will you expect? Customers? Daily tickets?
You probably are fine but drive space is going to be more of a limiting factor over time than anything else you've mentioned.
It's really not fair to ask "limits" because there generally are none ... unless you know you're going to hammer this in very high levels (thousands of daily tickets), at which point, you may be in an environment where asking such a question on a free/volunteer forum is not optimal for your solution.
You probably are fine but drive space is going to be more of a limiting factor over time than anything else you've mentioned.
It's really not fair to ask "limits" because there generally are none ... unless you know you're going to hammer this in very high levels (thousands of daily tickets), at which point, you may be in an environment where asking such a question on a free/volunteer forum is not optimal for your solution.
OTRS 6.0.x (private/testing/public) on Linux with MySQL database.
Please edit your signature to include your OTRS version, Operating System, and database type.
Click Subscribe Topic below to get notifications. Consider amending your topic title to include [SOLVED] if it is so.
Need help? Before you ask
Please edit your signature to include your OTRS version, Operating System, and database type.
Click Subscribe Topic below to get notifications. Consider amending your topic title to include [SOLVED] if it is so.
Need help? Before you ask
Re: OTRS performance limits
Thanks for quick reply. Sorry for misunderstanding: we already have the installation:
OTRS 3.1.2
~100-150 simultaneous agents working
~2.000-3.000 tickets/day
~950 queues
~200 mail account downloads
~1.850 mail filters
~3.500.000 total tickets (850.000 "active"=not archived)
MySQL myISAM tables
The system is sometimes slow. We are limiting fulltext searches and reports, but we suspect it's not enough.
What we should understand, before growing more, is if there are limits in OTRS architecture or if the bottleneck is in mysql configuration or architecture itself.
In the former case we shoud plan to split installation, in the latter case we can try mirrored db with loadbalance.
I agree this is not usual for many environments, but maybe some "heavy" user can be found here in the forum.
I really can't find any benchmark for OTRS on the web ...
Any help is appreciated
g
OTRS 3.1.2
~100-150 simultaneous agents working
~2.000-3.000 tickets/day
~950 queues
~200 mail account downloads
~1.850 mail filters
~3.500.000 total tickets (850.000 "active"=not archived)
MySQL myISAM tables
The system is sometimes slow. We are limiting fulltext searches and reports, but we suspect it's not enough.
What we should understand, before growing more, is if there are limits in OTRS architecture or if the bottleneck is in mysql configuration or architecture itself.
In the former case we shoud plan to split installation, in the latter case we can try mirrored db with loadbalance.
I agree this is not usual for many environments, but maybe some "heavy" user can be found here in the forum.
I really can't find any benchmark for OTRS on the web ...
Any help is appreciated
g
-
- Moderator
- Posts: 10170
- Joined: 04 May 2010, 18:38
- Znuny Version: 5.0.x
- Location: SouthWest Florida, USA
- Contact:
Re: OTRS performance limits
You may wish to seek paid support from someone... also note that below 3.3.x and 4.0.x are no longer supported by OTRS proper (not that this forum is official OTRS support anyway) but at least be uptoday on 3.1.latest for bug and security reasons.
Your sluggishness may be for multiple different reasons, and it's not practical to throw out suggestions *in general* in a forum such as this with a possibility of you replying to many of them, "But we tried that. And we tried that as well."
There are lots of different things... filesystem versus database handling of attachments? receiving email directly instead of pop'ing them? High performance database tweaks. Upgrading OS. Upgrading Database. Applying OS and application updates. Most of these I'm expecting that you've already looked at (except when you're going to upgrade OTRS, apparently).
check OS top command for CPU hogs. Check your filesystem for corruption. Test your disaster recovery plan.
Your sluggishness may be for multiple different reasons, and it's not practical to throw out suggestions *in general* in a forum such as this with a possibility of you replying to many of them, "But we tried that. And we tried that as well."
There are lots of different things... filesystem versus database handling of attachments? receiving email directly instead of pop'ing them? High performance database tweaks. Upgrading OS. Upgrading Database. Applying OS and application updates. Most of these I'm expecting that you've already looked at (except when you're going to upgrade OTRS, apparently).
check OS top command for CPU hogs. Check your filesystem for corruption. Test your disaster recovery plan.
OTRS 6.0.x (private/testing/public) on Linux with MySQL database.
Please edit your signature to include your OTRS version, Operating System, and database type.
Click Subscribe Topic below to get notifications. Consider amending your topic title to include [SOLVED] if it is so.
Need help? Before you ask
Please edit your signature to include your OTRS version, Operating System, and database type.
Click Subscribe Topic below to get notifications. Consider amending your topic title to include [SOLVED] if it is so.
Need help? Before you ask
Re: OTRS performance limits
You're right for all about upgrades. Otherwise, it is very difficult to maintain such a system with small downtime, as you can imagine ...
About attachements on filesystem: it is done.
About pulling mails from a mailserver that is actually on the same machine: good suggestion. But I'don't know if it will be possible to move all mail domains. I'll try to suggest this as an improvement.
Database tweaks: we already raised all mysql buffers size, cache size, we set SELECT priority against UPDATE. Maybe some mysql guru can read our mysqlreport better than us. I have to find such guy as fast as possible
Performance: HTOP shows load averages below 3 (32CPU) with low cpu usage and little waiting answer (%wa<4) for few seconds, IO load is below 4000B/s. RAM is almost time 60% free. During slowdown episodes the only problematic parameter seems %wa, but this parameter is something mysteriorious to me
Maybe we can migrate to InnoDB tables, but I read this is doesn't mean best db performance in every cases.
We will plan tables optimization, of course. I know it helps and we should plan a long downtime for that
But I always look for someone telling me "No, your system OTRS+MySQL can't manage such loads" or, as I whish, "The numbers you want to manage are ok for OTRS+MySQL". In this case we will take into consideration paid support to go on.
Maybe I have to ask to OTRS staff, as you suggest.
Thanks so much for your help.
g
About attachements on filesystem: it is done.
About pulling mails from a mailserver that is actually on the same machine: good suggestion. But I'don't know if it will be possible to move all mail domains. I'll try to suggest this as an improvement.
Database tweaks: we already raised all mysql buffers size, cache size, we set SELECT priority against UPDATE. Maybe some mysql guru can read our mysqlreport better than us. I have to find such guy as fast as possible

Performance: HTOP shows load averages below 3 (32CPU) with low cpu usage and little waiting answer (%wa<4) for few seconds, IO load is below 4000B/s. RAM is almost time 60% free. During slowdown episodes the only problematic parameter seems %wa, but this parameter is something mysteriorious to me

Maybe we can migrate to InnoDB tables, but I read this is doesn't mean best db performance in every cases.
We will plan tables optimization, of course. I know it helps and we should plan a long downtime for that

But I always look for someone telling me "No, your system OTRS+MySQL can't manage such loads" or, as I whish, "The numbers you want to manage are ok for OTRS+MySQL". In this case we will take into consideration paid support to go on.
Maybe I have to ask to OTRS staff, as you suggest.
Thanks so much for your help.
g
-
- Moderator
- Posts: 10170
- Joined: 04 May 2010, 18:38
- Znuny Version: 5.0.x
- Location: SouthWest Florida, USA
- Contact:
Re: OTRS performance limits
:) no, just forward to the machine and use procmail to let OTRS handle the tickets immediately instead of polling.gdavid wrote:About pulling mails from a mailserver that is actually on the same machine: good suggestion.
viewtopic.php?t=16009#p91142
Also, you will have no choice but to migrate to InnoDB tables beyond 3.1.
OTRS 6.0.x (private/testing/public) on Linux with MySQL database.
Please edit your signature to include your OTRS version, Operating System, and database type.
Click Subscribe Topic below to get notifications. Consider amending your topic title to include [SOLVED] if it is so.
Need help? Before you ask
Please edit your signature to include your OTRS version, Operating System, and database type.
Click Subscribe Topic below to get notifications. Consider amending your topic title to include [SOLVED] if it is so.
Need help? Before you ask