Random timeouts on Riak

Jason Ryan jason.ryan at trustev.com
Tue Dec 30 06:30:37 EST 2014


It was enabled by default - we didn't change this value when creating the
bucket. The only properties on the bucket that we changed were allow_mult
and last_write_wins.

Further update - yesterday we also noticed in the logs that one of our
keys, its JSON had grown to 17MB after some load tests, we hadn't expected
it to be that size and wouldn't normally grow to that in production (it's
just a side issue of the load testing scenario) - however we know that is a
huge key for Riak, so we deleted it and now the random timeouts on the keys
we were having have stopped... could that large key be manifesting an issue
down the line on accessing other keys? The large key would be fetched as
part of our test scenario, but maybe the issue isn't bubbling up until one
of the smaller keys is accessed?



On 30 December 2014 at 11:19, Russell Brown <russell.brown at me.com> wrote:

>
> On 30 Dec 2014, at 11:16, Jason Ryan <jason.ryan at trustev.com> wrote:
>
> Hi Russell,
>
> Bucket Properties are:
>
> young_vclock: 20
> w: quorum
> small_vclock: 50
> rw: quorum
> r: quorum
> pw: 0
> precommit: []
> pr: 0
> postcommit: []
> old_vclock: 86400
> notfound_ok: true
> n_val: 3
> linkfun: {modfun,riak_kv_wm_link_walker,mapreduce_linkfun}
> last_write_wins: true
> dw: quorum
> dvv_enabled: true
>
>
> Interesting. So this is a default bucket on which you enabled DVV? Or a
> bucket type bucket (which has DVV enabled by default?)
>
> chash_keyfun: {riak_core_util,chash_std_keyfun}
> big_vclock: 50
> basic_quorum: false
> allow_mult: false
> active: true
> claimant: 'n1 at 10.2.4.5'
>
> Jason
>
> [image: photo]
> *Jason Ryan*
> VP Engineering
>
> Trustev
> Real Time, Online Identity Verification
>
> email: jason.ryan at trustev.com
> skype: jason_j_ryan
> web: www.trustev.com
>
> Trustev Ltd, 2100 Cork Airport Business Park, Cork, Ireland.
>
> On 30 December 2014 at 08:49, Russell Brown <russell.brown at me.com> wrote:
>
>> Please can you let me know if you’re using a typed or default bucket?
>>
>> Please can you let me know what you’re DVV setting is?
>>
>> On 29 Dec 2014, at 12:27, Jason Ryan <jason.ryan at trustev.com> wrote:
>>
>> Also we noticed these warnings - should we change the environment to make
>> these on each node?
>>
>> 2014-12-29 11:32:14.564 [warning] <0.339.0> riak_kv_env: sysctl
>> net.core.rmem_max is 124928, should be at least 8388608)
>> 2014-12-29 11:32:14.564 [warning] <0.339.0> riak_kv_env: sysctl
>> net.core.netdev_max_backlog is 1000, should be at least 10000)
>> 2014-12-29 11:32:14.564 [warning] <0.339.0> riak_kv_env: sysctl
>> net.core.somaxconn is 128, should be at least 40000)
>> 2014-12-29 11:32:14.564 [warning] <0.339.0> riak_kv_env: sysctl
>> net.ipv4.tcp_max_syn_backlog is 2048, should be at least 40000)
>> 2014-12-29 11:32:14.565 [warning] <0.339.0> riak_kv_env: sysctl
>> net.ipv4.tcp_fin_timeout is 60, should be no more than 15)
>> 2014-12-29 11:32:14.565 [warning] <0.339.0> riak_kv_env: sysctl
>> net.ipv4.tcp_keepalive_intvl is 75
>> , should be no more than 30)
>> 2014-12-29 11:32:14.565 [warning] <0.339.0> riak_kv_env: sysctl
>> net.ipv4.tcp_tw_reuse is 0, should be 1)
>> 2014-12-29 11:33:02.528 [warning] <10924.36.0> OS_MON (memsup) called by
>> <10924.36.0>, not started
>> 2014-12-29 11:33:02.534 [warning] <10924.45.0> OS_MON (memsup) called by
>> <10924.45.0>, not started
>>
>>
>>
>>
>>
>> On 29 December 2014 at 12:08, Sargun Dhillon <sargun at sargun.me> wrote:
>>
>>> The bucket (type) that you're working with -- what are your
>>> allow_mult, and last_write_wins settings?
>>>
>>> On Mon, Dec 29, 2014 at 4:05 AM, Jason Ryan <jason.ryan at trustev.com>
>>> wrote:
>>> > It seems to move between 4 keys in particular, these keys are actually
>>> empty
>>> > at the moment (i.e. an empty JSON document).
>>> >
>>> > CPU utilization is close to zero.
>>> >
>>> > Can't see anything in particular, bar the error message I just posted
>>> > before.
>>> >
>>> > Jason
>>> >
>>> >
>>> > On 29 December 2014 at 11:58, Ciprian Manea <ciprian at basho.com> wrote:
>>> >>
>>> >> Hi Jason,
>>> >>
>>> >> Are these random timeouts happening for only one key, or is common for
>>> >> more?
>>> >>
>>> >> What is the CPU utilisation in the cluster when you're experience
>>> these
>>> >> timeouts?
>>> >>
>>> >> Can you spot anything peculiar in your server's $ dmesg outputs? Any
>>> I/O
>>> >> errors there?
>>> >>
>>> >>
>>> >> Regards,
>>> >> Ciprian
>>> >>
>>> >> On Mon, Dec 29, 2014 at 1:55 PM, Sargun Dhillon <sargun at sargun.me>
>>> wrote:
>>> >>>
>>> >>> Several things:
>>> >>> 1) I recommend you have a 5-node cluster:
>>> >>>
>>> http://basho.com/why-your-riak-cluster-should-have-at-least-five-nodes/
>>> >>> 2) What version of Riak are you using?
>>> >>> 3) What backend(s) are you using?
>>> >>> 4) What's the size of your keyspace?
>>> >>> 5) Are you actively rewriting keys, or writing keys to the cluster?
>>> >>> 6) Do you know how much I/O the cluster is currently doing?
>>> >>>
>>> >>> On Mon, Dec 29, 2014 at 2:51 AM, Jason Ryan <jason.ryan at trustev.com>
>>> >>> wrote:
>>> >>> > Hi,
>>> >>> >
>>> >>> > We are getting random timeouts from our application (>60seconds)
>>> when
>>> >>> > we try
>>> >>> > to retrieve a key from our Riak cluster (4 nodes with a load
>>> balancer
>>> >>> > in
>>> >>> > front of them). Our application just uses the standard REST API to
>>> >>> > query
>>> >>> > Riak.
>>> >>> >
>>> >>> > We are pretty new to Riak - so would like to understand how best to
>>> >>> > debug
>>> >>> > this issue? Is there any good pointers on what to start with? This
>>> is
>>> >>> > our
>>> >>> > production cluster.
>>> >>> >
>>> >>> > Thanks,
>>> >>> > Jason
>>> >>> >
>>> >>> >
>>> >>> > This message is for the named person's use only. If you received
>>> this
>>> >>> > message in error, please immediately delete it and all copies and
>>> >>> > notify the
>>> >>> > sender. You must not, directly or indirectly, use, disclose,
>>> >>> > distribute,
>>> >>> > print, or copy any part of this message if you are not the intended
>>> >>> > recipient. Any views expressed in this message are those of the
>>> >>> > individual
>>> >>> > sender and not Trustev Ltd. Trustev is registered in Ireland No.
>>> 516425
>>> >>> > and
>>> >>> > trades from 2100 Cork Airport Business Park, Cork, Ireland.
>>> >>> >
>>> >>> >
>>> >>> > _______________________________________________
>>> >>> > riak-users mailing list
>>> >>> > riak-users at lists.basho.com
>>> >>> > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>> >>> >
>>> >>>
>>> >>> _______________________________________________
>>> >>> riak-users mailing list
>>> >>> riak-users at lists.basho.com
>>> >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>> >>
>>> >>
>>> >
>>> >
>>> > This message is for the named person's use only. If you received this
>>> > message in error, please immediately delete it and all copies and
>>> notify the
>>> > sender. You must not, directly or indirectly, use, disclose,
>>> distribute,
>>> > print, or copy any part of this message if you are not the intended
>>> > recipient. Any views expressed in this message are those of the
>>> individual
>>> > sender and not Trustev Ltd. Trustev is registered in Ireland No.
>>> 516425 and
>>> > trades from 2100 Cork Airport Business Park, Cork, Ireland.
>>>
>>
>>
>> This message is for the named person's use only. If you received this
>> message in error, please immediately delete it and all copies and notify
>> the sender. You must not, directly or indirectly, use, disclose,
>> distribute, print, or copy any part of this message if you are not the
>> intended recipient. Any views expressed in this message are those of the
>> individual sender and not Trustev Ltd. Trustev is registered in Ireland
>> No. 516425 and trades from 2100 Cork Airport Business Park, Cork, Ireland.
>> _______________________________________________
>> riak-users mailing list
>> riak-users at lists.basho.com
>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>
>>
>>
>
> This message is for the named person's use only. If you received this
> message in error, please immediately delete it and all copies and notify
> the sender. You must not, directly or indirectly, use, disclose,
> distribute, print, or copy any part of this message if you are not the
> intended recipient. Any views expressed in this message are those of the
> individual sender and not Trustev Ltd. Trustev is registered in Ireland
> No. 516425 and trades from 2100 Cork Airport Business Park, Cork, Ireland.
>
>
>

-- 


This message is for the named person's use only. If you received this 
message in error, please immediately delete it and all copies and notify 
the sender. You must not, directly or indirectly, use, disclose, 
distribute, print, or copy any part of this message if you are not the 
intended recipient. Any views expressed in this message are those of the 
individual sender and not Trustev Ltd. Trustev is registered in Ireland No. 
516425 and trades from 2100 Cork Airport Business Park, Cork, Ireland.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20141230/4074305f/attachment.html>


More information about the riak-users mailing list