Heh. I had a funny feeling that was going to be the answer. I was curious
mostly because the Binary mode seemed to do quite a deal of good for
Facebook when it was used. I'm imagining that they cached images so binary
was a good idea, but for simple structures like json, it might not make much
sens
On Feb 21, 12:31 am, Patrick Santora wrote:
> Heh. I had a funny feeling that was going to be the answer. I was curious
> mostly because the Binary mode seemed to do quite a deal of good for
> Facebook when it was used. I'm imagining that they cached images so binary
> was a good idea, but for si
@Dustin
Thanks, I will be disabling them to see if that helps.
-Pat
On Mon, Feb 21, 2011 at 5:59 AM, Dustin wrote:
>
> On Feb 21, 12:31 am, Patrick Santora wrote:
> > Heh. I had a funny feeling that was going to be the answer. I was curious
> > mostly because the Binary mode seemed to do quite
gcc otimization? there´s some compile for small size, and compile for
fast code... must try, i never used
2011/2/21 aaliya zarrin :
> Thanks,
> I don't want to use strip, because it will remove the debug symbole.
> I want the debus symbole as well.
> Any other way?
>
> On Fri, Feb 18, 2011 at 10:0
Hrmm. Still having issues. Here is the latest stats dump. I also talked with
my IT person and he mentioned the following setup, which does not look like
an issue?
NIC SETTINGS
the servers should all be autonegotiating to 100/Full and we apply these
additional kernel tuning parameters
net.core.rmem_
Have you walked through those links I gave you? You haven't mentioned
exactly what you're seeing and those links walk you through narrowing it
down a lot as well as listing a lot of things to look for.
On Mon, 21 Feb 2011, Patrick Santora wrote:
> Hrmm. Still having issues. Here is the latest sta
I will need to look at those further today. This weekend went a little
haywire for me. :)
On Feb 21, 2011 11:42 AM, "dormando" wrote:
> Have you walked through those links I gave you? You haven't mentioned
> exactly what you're seeing and those links walk you through narrowing it
> down a lot as
On 16. feb. 2011, at 18.06, Paul Lindner wrote:
> Thanks! I was going to fix this today but you beat me to it..
>
> ccing memcached in hopes that it will get incorporated upstream...
>
I tried to apply the patch today, but it failed (probably due to my poor
removal of "> ". Anyway. I contact
So initial testing via those links have not caused the bottleneck I have
been seeing. I am going to test further and have started to also investigate
the use of spymemcached client since it looks to be a recommended client to
use.
On Feb 21, 2011 11:51 AM, "Patrick Santora" wrote:
> I will need to
Its just strange. Memcaced with verbose logging looks ok but the client
machines just take forever to get data. Like in the stats I don't see
anything out of the ordinary. The nic settings look ok too. Quite
frustrating...
On Feb 21, 2011 11:51 AM, "Patrick Santora" wrote:
> I will need to look at
Have you been running the connection tester tool while observing the
client slowdown?
The tool is there so you can rule if your client is an issue or not, ie;
if the tool never sees a blip but all/most/some of your clients are seeing
blips, it's the client's fault. If the tool sees a blip, you can
Yeah. I will run it the next time the issue comes up. Does it matter if I
run the tester on the same box the clients on? It should not matter but
thought ii would ask.
Thanks!
On Feb 21, 2011 6:25 PM, "dormando" wrote:
> Have you been running the connection tester tool while observing the
> clien
You may want to try xmecached ,here is a benchmark
http://xmemcached.googlecode.com/svn/trunk/benchmark/benchmark.html
2011/2/22 Patrick Santora
> Yeah. I will run it the next time the issue comes up. Does it matter if I
> run the tester on the same box the clients on? It should not matter but
>
Yeah I looked into that one. I have it in my back pocket just in case.
Unless im told I should use that over spymemcached.
On Feb 21, 2011 7:49 PM, "boyan" wrote:
> You may want to try xmecached ,here is a benchmark
> http://xmemcached.googlecode.com/svn/trunk/benchmark/benchmark.html
>
> 2011/2/2
Patrick, are you sure the time is not spent GC'ing? Are you using icms
(-XX:+UseConcMarkSweepGC)? Is your verbose gc logging on?
On Mon, Feb 21, 2011 at 9:23 PM, Patrick Santora wrote:
> Its just strange. Memcaced with verbose logging looks ok but the client
> machines just take forever to get da
Run two, and keep them running all the time, so you see log from
before/after. You can also enable the "debug" switch and have it log
everything.
So yeah. run one on the client and one on an idle machine elsewhere.
On Mon, 21 Feb 2011, Patrick Santora wrote:
>
> Yeah. I will run it the next time
Yeah I have the debug switch on. Thanks for the recommendation on running it
in two places. I will give that a shot. I saw that the set and get times
will be 0 if there is anything wrong via the debug. I take it if that's the
case then I should look into what the verbose logs give me? Is there
anyt
17 matches
Mail list logo
