Well if you have evictions, you're probably out of memory? This isn't what
you were saying before though.

Get moar memoryyy?

On Mon, 30 Jul 2012, U.S. Adha wrote:

> Hi Dormando,                   Thanks for reply. Looks like this works a bit, 
> but it start evictions objects after 50 Millions object inserted into 
> memcached. I am using memcached 1.4.7 at this time. Also I have tried with 
> memcached 1.4.13 too, but same issue was
> there too. Now am starting memcached with this 
>
>
> memcached -m 8000 -l 127.0.0.1 -p 11211 9000 9 > log_nine_seconds
>
> yet my memcached evicting object...look stats
>
> STAT reclaimed 0
> END
> stats
> STAT pid 5300
> STAT uptime 3801
> STAT time 1343635673
> STAT version 1.4.7
> STAT libevent 2.0.12-stable
> STAT pointer_size 64
> STAT rusage_user 500.823299
> STAT rusage_system 486.058376
> STAT curr_connections 5
> STAT total_connections 37434
> STAT connection_structures 27
> STAT cmd_get 154795
> STAT cmd_set 63614971
> STAT cmd_flush 0
> STAT get_hits 154795
> STAT get_misses 0
> STAT delete_misses 0
> STAT delete_hits 0
> STAT incr_misses 0
> STAT incr_hits 0
> STAT decr_misses 0
> STAT decr_hits 0
> STAT cas_misses 0
> STAT cas_hits 0
> STAT cas_badval 0
> STAT auth_cmds 0
> STAT auth_errors 0
> STAT bytes_read 5421185438
> STAT bytes_written 512116959
> STAT limit_maxbytes 8388608000
> STAT accepting_conns 1
> STAT listen_disabled_num 0
> STAT threads 4
> STAT conn_yields 19532
> STAT bytes 7523088744
> STAT curr_items 55177103
> STAT total_items 63614971
> STAT evictions 8325645
> STAT reclaimed 0
>
>
>
>
>
>
> On Saturday, July 28, 2012 1:06:37 AM UTC+5:30, Dormando wrote:
>       Your startup options are bizarre...
>
>       memcached -m 8000 -l 127.0.0.1 -p 11211
>       ^ just do that. don't add -L or -R and see if that helps any.
>
>       Also, we need to know the version and make of the client you're using. 
> Any
>       example code or data for how you're trying to load it will be required 
> to
>       see what's happening.
>
>       Your client should be doing something weird to end up in that state.
>       Memcached is trying to write back to your client but the socket is 
> closed
>       for some reason.
>
>       On Fri, 27 Jul 2012, U.S. Adha wrote:
>
>       > Yes, I tried without  -vv option. It seem like, it's speed increase a 
> bit faster but not much as I expect. But this issue
>       > remain...................."Failed to write, and not due to blocking: 
> Connection reset by peer "
>       >
>       >
>       >
>       >
>       > On Friday, July 27, 2012 3:05:59 PM UTC+5:30, U.S. Adha wrote:
>       >       Yes, I tried with -vv option. It seem like, it's speed increase 
> a bit faster but not much as I expect. But this issue
>       >       remain...................."Failed to write, and not due to 
> blocking: Connection reset by peer "
>       >
>       >
>       >
>       > On Friday, July 27, 2012 3:03:48 PM UTC+5:30, Martin Hellmich wrote:
>       >       Have you tried the same without the -vv switch?
>       >       I experienced memcached to be much faster without the logging.
>       >       Martin
>       >
>       >       On 07/27/2012 11:29 AM, U.S. Adha wrote:
>       >       > Hi, thanks for reply me. yet am fighting with same issue, am 
> trying to put data into memcached via java client and am trying to
>       >       put 60 million object into memcached. I am using this command 
> to start memcached
>       >       >
>       >       > memcached -d -vv -m 8000 -l 127.0.0.1 -p 11211 -c 250 -L 2048 
> -R 100 1000 10 > log_ten_seconds
>       >       >
>       >       > but after putting 20 million objects memcached give me error 
> like
>       >       >
>       >       > Failed to write, and not due to blocking: Connection reset by 
> peer
>       >       > <80 connection closed.
>       >       > Failed to write, and not due to blocking: Connection reset by 
> peer
>       >       >
>       >       >
>       >       > Am not sure, where am having problem......I really appreciate 
> if you help me to get-out of this hall.
>       >       >
>       >       >
>       >       >
>       >       >
>       >       >
>       >       >
>       >       >
>       >       >
>       >       >
>       >       >
>       >       > On Wednesday, November 30, 2011 3:33:53 PM UTC+5:30, ktechie 
> wrote:
>       >       >
>       >       >     My configuration is VMware on Red hat 64bit linux OS.  
> Memcached 1.4.5
>       >       >     and Xmemcached 1.3.5.
>       >       >     I have a program which does eager loading of data, which 
> is about 3GB,
>       >       >     this happens through a multithreaded application, with 10 
> threads
>       >       >     I have also created a connection pool of 50 connections 
> to memcached.
>       >       >     There is also a listener which tells when there is 
> disconnection or
>       >       >     the connection is healed.
>       >       >
>       >       >     Sometimes the program works fine without errors, but at 
> times when I
>       >       >     see disconnections and connections happening many times.
>       >       >     And the memcached server gives the following errors.
>       >       >
>       >       >     Failed to write, and not due to blocking: Connection 
> reset by peer
>       >       >     Failed to read, and not due to blocking:
>       >       >     errno: 104 Connection reset by peer
>       >       >     rcurr=127980b8 ritem=1442bd8a rbuf=12797c00 rlbytes=550 
> rsize=2048
>       >       >
>       >       >     When this happens the data is not fully loaded.
>       >       >
>       >       >     At times this issue is resolved after the VM is rebooted. 
>  but that is
>       >       >     not always the case.
>       >       >     I tried reducing the connection pool size to 1 and thread 
> pool to 1,
>       >       >     even then the disconnections could happen
>       >       >
>       >       >     What could be the possible reasons for this.
>       >       >
>       >
>       >       --
>       >       Martin Hellmich                    Information Technology 
> Department
>       >       [email protected]                                                
> CERN
>       >       +41 22 76 765 26                                   CH-1211 
> Geneva 23
>       >
>       >
>       >
>
>
>

Reply via email to