beta 4 - Upgrade issue : This action is available via POST only.
- Thread starter Andy.N
- Start date
Deebs
Well-known member
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.
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.
Deebs
Well-known member
Possibly, I have just converted my live forums to Libmemcached (advanced version of memcached) and so far so good. Let me grab a pic...
R
ragtek
Guest
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
http://highscalability.com/bunch-great-strategies-using-memcached-and-mysql-better-together
)Edit: found it
http://highscalability.com/bunch-great-strategies-using-memcached-and-mysql-better-together
Deebs
Well-known member
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.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
http://highscalability.com/bunch-great-strategies-using-memcached-and-mysql-better-together
Deebs
Well-known member
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 ?
F
Floris
Guest
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.
dieketzer
Well-known member
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?
Deebs
Well-known member
Firstly,
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)
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.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
Deebs
Well-known member
Mike,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.
Similar threads
- Question
- Question