+4Hello all,
We're running JSS 9.101 and have noticed during scheduled database backups (using JSSDatabaseUtil.jar on Red Hat) that the JSS web interface is either super slow or just all out unresponsive. Once the backup ends, all is well again.
It's fine if this is expected behavior; I'm just curious if this is normal.
Thanks
+25I was seeing this as well. Turns out it was because of a bloated Applications table. If we were to truncate or clean up that applications table everything was fine. It was actually to the point that I had to actually reboot the JSS after the backup finished in order to gain access back to my JSS.
+18This will happen with any or the larger MyISAM DB tables during repair. MySQL connections (we are load balanced) max out. We had to stop doing nightly backups because of this. I run them manually (and eventually via script) on Saturday mornings...
+4ddcdennisb, what is your definition of a bloated application table? Any idea of how many records we're talking about before you started having the issue?
dgreening, why would the tables be repaired?
+25When i saw my applications table getting to the 2-5GB in size is when we were seeing the issue.
During the backups, every table runs a repair.
+13
Hey all..
It's defintely the "Applications" table thats screwing everyhting up!!
I went ahead and truncated it and I successfully backed up the daytabase sharpish!
On further inspection, the 'mac_app_store' field is the culprit.
I 'zeroed' it 2 days ago and it's now showing a count of , wait for it, 4 million 213 tousand and 953!
It keeps adding records that contain NO data!
Log flushing does NOT help!
There is a way to keep only the last entries, which I have attached.
I have logged a support call for this and I'll keep this thread updated.
G'LUCK!
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.