Discussion in 'Installation, Upgrade, and Import Support' started by Andy.N, Oct 27, 2011.
Ok, now she is looking like this:
Would you just look at those hit/miss rate?
No wonder I had trouble with this 30MB APC. 128MB would make her much happier.
Thank a ton, Deebs
You are most welcome, pleasure to help. Enjoy the speed boost. I am certain it you will notice it.
I also took the liberty of upgrading you from a poor version of APC to a much better version.
I'm not even sure what half this thread's about but speed boosts are awesome.
Appreciate all the help.
I also took the liberty of adding the new user session caching in beta 4 to the config file $config['cache']['cacheSessions'] = true;
Do you think I would benefit from having memcache installed on the sql server since we have a separate server for it.
Possibly, I have just converted my live forums to Libmemcached (advanced version of memcached) and so far so good. Let me grab a pic...
Hm, i would prefer to have ONLY mysql on the server and to give it all the possible memory. (but only because i've read it some years ago )
Edit: found it
I have a server with 2GB ram for just mysql and nothing else on it.
XenForo requires a small amount of RAM for the vars and session tables in comparision to a MySQL installation. Having said that, Andy has over 3.5gb RAM free on his webserver so could happily run Memcached there.
what a nightmare this has turned out to be.
ive completely disabled apc for the time being.
The biggest problem with using APC, as Mike as stated, is not having enough capacity to store the vars/sessions in the cache. Have you got any stats ?
Why is this needed? Without it the apc.php user-caching already shows the sessions being cached?
In the next release, it's specifically opt-in to pull the sessions from the cache to prevent issues like these.
Okidoki, added to my config.php =D
the real nightmare was not being able to login to the acp within 10 minutes of the update, right in the middle of my revert/reapply templating work. eventually i found my way to this thread, then disabled apc.
its worth noting that i didnt opt in to this new session jazz. it might not be a great idea to have this happen to people in 1.1 final.
here are some stats. its (seemingly) run happily with 30 mb for nearly a year now. its running 30 mb cos i heard from people that 30 was some sort of magic number.
if i need to increase this or whatnot i can do that, but for time being my only worry is actual acp access.
what do these numbers relate to you?
That is a way old version of APC and I would recommend uprading to 3.1.9.
The magic number of 30 comes from the fact that many old distros of Linux came with a maximum shared memory setting of 32MB out of the box. Personally I would increase the shared memory size of your server first, then increase the APC memory to 64MB. This will hopefully stop the Cache Full Counts but it will not stop fragmentation (Not seen anywhere that has effectively stopped fragmentation on an APC install running after a few hours)
The opt-in is only in the next release, specifically to resolve this issue.
I would recommend increasing it -- the numbers aren't huge (yet), but you can see that you have some "cache full count" entries, which means that something couldn't be cached when it was requested. Regardless of the amount of free memory it says if has, if you're having cache full counts, it'd be worthwhile to increase the amount of memory available to it.
APC has the ability to use multiple SHM segments to workaround this.
I used to run 4 segments but the caches would still fragment. Perhaps I should try with 3.1.9.
For my variable storage I have implemented Libmemcached with enabled igbinary support and changed PHP session.serialize_handler=igbinary (for that little extra performance).
Sorry, I was referring to the max amount of memory it can use -- if you can only use 32MB, you can still get a bigger cache with 2 segments. I doubt you can really prevent segmentation. That's something that APC would need to clean up internally.
Separate names with a comma.