Thank you for your responses.
In the last several days we have gotten a much better understanding of
memcache in general and how we use it.
A little more background to help you understand the current state:
We have 4 live servers that are all supposed to be identical. Our code is
in PHP.
Thank you for your responses.
In the last several days we have gotten a much better understanding of
memcache in general and how we use it.
A little more background to help you understand the current state:
We have 4 live servers that are all supposed to be identical. Our
code is in PHP. We
Hi Dormando,
Thanks for your response.
On 06/02/2011 23:44, dormando wrote:
I've found (part of) the answer to my own question - the virtual
memory comes from the thread stacks. Setting -t 1 reduces the virtual
memory to around 20MB.
I've read from other posts that it is no longer possible
If it helps, you could reduce the stack size on linux using ulimit -s
stackSizeInKB)
thanks!
rohitk
On Mon, Feb 7, 2011 at 1:32 PM, letmewatch.TV
pay.letmewatch...@gmail.comwrote:
Hi Dormando,
Thanks for your response.
On 06/02/2011 23:44, dormando wrote:
I've found (part of) the answer
Rohit,
Thanks for your reply. That works very well, thanks - it's now reduced
to just a few MB's virtual mem.
I'll need to check what stack size is appropriate for the memcached
threads, but I'm guessing it's probably not more than 64 or 128KB.
I'll add an issue notice to the memcached
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 186 by pay.letm...@gmail.com: Thread stack size should be set
explicitly to reduce virtual memory usage
http://code.google.com/p/memcached/issues/detail?id=186
The problem
---
The default thread stack size is much
Seriously, this is not a problem you should be concerned about, and you
should not spend time creating some weird over-engineered solution that
solves a problem you didn't have in the first place. Use memcached the way
it's supposed to be used. Try it out. Measure response times. I'm pretty
sure
A few more questions we have:
1) How does memcached deal with a change in IP of a server? Does that
invalidate the whole cache in the same way as if I added or removed a
server?
2) We are also concerned about the number of open apache connections on a
machine at a given time. Currently we
i think you want raid1 of memcached?!
for write, make sure you wrote on all memcached, for read select any
one (that's online)
2011/2/7 Margalit Silver margalitatw...@gmail.com:
A few more questions we have:
1) How does memcached deal with a change in IP of a server? Does that
invalidate the
Comment #3 on issue 122 by rspa...@gmail.com: failed to write, and not due
blocking: No error
http://code.google.com/p/memcached/issues/detail?id=122
maybe problem with tcp/ip or arp table?
try with udp client/server protocol
Comment #4 on issue 122 by sean.y@gmail.com: failed to write, and not
due blocking: No error
http://code.google.com/p/memcached/issues/detail?id=122
Thanks. Could you please explain what are the possible problems with arp
table? If I use UDP, how can I make sure it's working fine
Comment #5 on issue 122 by sean.y@gmail.com: failed to write, and not
due blocking: No error
http://code.google.com/p/memcached/issues/detail?id=122
Thanks. Could you please explain what are the possible problems with arp
table? If I use UDP, how can I make sure it's working fine
for rtos:
EARPFULL (104)
ARP table full. This error is reported by send when the ARP cache is
full. If this error occurs, increase CFG_ARPCLEN.
for linux you can see this message in /var/log/messages:
21 messages suppressed Neighbour table overflow.
use this to get max values of arp table:
#
i think that you have a problem in arp, or tcp stack size
check netstat -a when this problem happen
after 2 minutes (is you tcp with 2minutes timeout? )
2011/2/7 Roberto Spadim robe...@spadim.com.br:
for rtos:
EARPFULL (104)
ARP table full. This error is reported by send when the ARP cache is
Comment #6 on issue 122 by dsalli...@gmail.com: failed to write, and not
due blocking: No error
http://code.google.com/p/memcached/issues/detail?id=122
I don't know why one might assume the problem is below layer 3 -- or even
outside of memcached itself.
It's likely to be related to the
no not below layer3, it´s a overfloow of table
many connections can cause this problem, try this command:
nmap -sP -T5 172.16.0.0/8
on linux you will get a table overflow (cache), wait some time and you
will get you network running again (i don´t know how to flush arp
cache)
2011/2/7
Thank you for not responding in the bug. I would like to reduce
confusion over there.
On Feb 7, 5:53 pm, Roberto Spadim robe...@spadim.com.br wrote:
no not below layer3, it´s a overfloow of table
ARP is a mechanism to find layer 3 addresses on layer 2.
I still don't see why you believe
can you try the same process but with UDP protocol? maybe it's a TCP
problem (not a memcached problem)
i'm thinking about possible problems, if you don't want to try it...
on linux i had the same problem but with another software (network
file system, and apache) no error code was reported, but
Hi,
I've been trying to find resources online to address a few questions i
had regarding the various configuration options available with
Memcached client/server without much success.
Heres how my setup would look like
i'd have two web servers [amazon EC2 instances] load balancing
incoming
1) some libraries implement hash to stripe informations (like raid0 do
with disks), you should use deterministic hash function (always set
the key, to the same server)
2) failover should be a mirror flag (like raid1 with disks), it should
write to all servers that variable (write on all servers =
Hi,
I don't want to be rude but can you perhaps stop advocating using UDP?
It's not actually faster if using persistent connections and is full of
bugs and limitations (like a max packet size of 1.4k).
Uhm. Actually in general your information is a little off from how we
usually go about things;
I've been trying to find resources online to address a few questions i
had regarding the various configuration options available with
Memcached client/server without much success.
The wiki at http://memcached.org/wiki has most of this, though perhaps not
in the most clear way. The old FAQ has
#1) Should i use consistent hashing.
I am not expecting instances to go down randomly. But whenever one
machine has to be taken out for maintenance etc, would like to
minimize the impact. i read about a reduced performance when switched
to consistent hashing. Not sure whether it is still
not about faster or not, the point of udp is the ram used to allow tcp
connection alive, udp don't need ram to allow connections (just server
side, or when send/receive package), it's connectionless... (you know,
i know, everyone that use it know)
with many clients (more than 1) udp for my
just a obs
hash is for server selection, a fast hash function = no problems on
performance (low latency)
in some libraries you can do your hash function too, read source code
and documents of you client library (for a better help in memcached
mail group, use memcached based libraries, try to not
check this discussion for more info about UDP pratical informations (not theory)
http://stackoverflow.com/questions/1098897/what-is-the-largest-safe-udp-packet-size-on-the-internet
http://www.29west.com/docs/THPM/packet-loss-myths.html
check that TCP can loss packets (any protocol without RTS
Yes that's the point. It loses some packets then scales back. Beats having
the machine drop offline.
On Tue, 8 Feb 2011, Roberto Spadim wrote:
check this discussion for more info about UDP pratical informations (not
theory)
Well you were saying speed is the point, but RAM is there as well.
If you properly tune the TCP stack the memory usage isn't bad at all. I've
ran a number of hosts with 100,000+ tcp connections on them at once and
while RAM gets sorta heavy it doesn't implode or anything. I say things
based on
s/leaks/leads to
On Mon, 7 Feb 2011, dormando wrote:
Well you were saying speed is the point, but RAM is there as well.
If you properly tune the TCP stack the memory usage isn't bad at all. I've
ran a number of hosts with 100,000+ tcp connections on them at once and
while RAM gets sorta
29 matches
Mail list logo
