Dear Zimbra Community,
We are very pleased of this software, since we've managed to fix some huge issues and so far the server was up and running with no issues at all for about 1 and 1/2 months. Today I've got again mini heart attack. An employee of our company, decided to delete 500+ messages (not more than 600), and after right clicking on Thrash folder and selecting Empty, the server went crazy. Nor the system (cpu, memory, swap) was overloaded but only the daemons start acting like there is HUGE overload. The SMTP port was answering with +30 seconds delay, the IMAP and IMAPSSL service were answering after 2 minutes upon connecting. We are using Zimbra 8.0.0 on CentOS 6.3 and the hardware is 2 Xeon x 2.4Ghz with 16Gb RAM and i don't think that the hardware is the problem.
So, is there anyone else who may faced such issues e.g. lagging of the service, daemons acting NOT normally etc. ?
Is there any other way to delete huge number of messages (like from console to delete specified folder with "rm" - it doesn't sound as good idea, but i'm digging arround)?
I appreciate ANY replies to this very much
Have a great day.
so far so good, another issue
-
- Outstanding Member
- Posts: 769
- Joined: Fri Sep 12, 2014 10:23 pm
so far so good, another issue
What kind of disks are you using? Are they local, or networked? Are you using virtualization?
so far so good, another issue
We are using 6x600Gb SATA disks in raid 6, but i really doubt that's the problem ...
-
- Outstanding Member
- Posts: 769
- Joined: Fri Sep 12, 2014 10:23 pm
so far so good, another issue
[quote user="ymarinov"]We are using 6x600Gb SATA disks in raid 6, but i really doubt that's the problem ...[/QUOTE]
The reason I asked is because when you do a delete, Zimbra issues an AJAX request with a comma separated list of all of the message id's, and then the server updates the mysql table and filesystem for each of the messages. So the two points of contention are going to be 1) the server disks or 2) the web browser. It may be #2. If there are a lot of messages, it will issue multiple requests, so it's possible that the browser is getting overloaded with javascript action at the time you are doing it.
One way to completely get rid of #1 is to make sure you have the dumpster feature enabled. That way only the MySQL table will get updated, and the messages will be deleted from disk behind the scenes at a later date.
The reason I asked is because when you do a delete, Zimbra issues an AJAX request with a comma separated list of all of the message id's, and then the server updates the mysql table and filesystem for each of the messages. So the two points of contention are going to be 1) the server disks or 2) the web browser. It may be #2. If there are a lot of messages, it will issue multiple requests, so it's possible that the browser is getting overloaded with javascript action at the time you are doing it.
One way to completely get rid of #1 is to make sure you have the dumpster feature enabled. That way only the MySQL table will get updated, and the messages will be deleted from disk behind the scenes at a later date.
- ccelis5215
- Outstanding Member
- Posts: 632
- Joined: Sat Sep 13, 2014 2:04 am
- Location: Caracas - Venezuela
- ZCS/ZD Version: 8.8.15.GA.3869.UBUNTU18.64 P12
so far so good, another issue
[quote user="Krishopper"]
One way to completely get rid of #1 is to make sure you have the dumpster feature enabled. That way only the MySQL table will get updated, and the messages will be deleted from disk behind the scenes at a later date.[/QUOTE]
A very good explanation!
ccelis
One way to completely get rid of #1 is to make sure you have the dumpster feature enabled. That way only the MySQL table will get updated, and the messages will be deleted from disk behind the scenes at a later date.[/QUOTE]
A very good explanation!
ccelis
so far so good, another issue
Ok, how should I set this option, and the other question is, how is even possible the browser to have something related of lagging service on a machine with 2x Xeon processors ?
-
- Ambassador
- Posts: 2747
- Joined: Mon Dec 16, 2013 11:35 am
- Location: France - Drôme
- ZCS/ZD Version: All of them
- Contact:
so far so good, another issue
Depending on the RAID controller, RAID6 goes from not so fast to very slow.
I'm not saying the issue is the RAID6. But RAID6 is not suggested (at all) for the primary volume (the one with the mysql data, new emails, mail queues, etc).
I'm not saying the issue is the RAID6. But RAID6 is not suggested (at all) for the primary volume (the one with the mysql data, new emails, mail queues, etc).