Hi,
we have some performance issues with our riak cluster, from time to time
we have a sudden drop in performance (already asked the list about this,
no-one had an idea though). Although not the same time but on the
problematic nodes we have a lot of these messages from time to time:
2013-04
Morning, Afternoon, Evening to All (from chilly London) -
We've got a great Recap for the last week or so. Blogs, new code,
slides, and much more.
Also, I'll be in London through Saturday. If anyone is in town and
wants to chat Riak over drinks, let me know.
Lastly, go buy a ticket for RICON EAS
Good to know. These are general caveats with relying too extensively on
Amazon, or trying to do too much with it, so I'll definitely keep these in
mind.
Tests will confirm if this approach will work at least under the initial
load we are expecting - once we have a lot of users server costs may no
Hi,
I'm trying to use riak with python.
I've installed the client (from github).
riak (1.2.0 2012-08-06) Debian x86_64
When I try to connect I got error:
AttributeError: 'module' object has no attribute 'RiakClient'
The code :
import riak
import uuid
import time
client = riak.RiakClient()
inline:
On Apr 2, 2013, at 6:48 PM, Matthew MacClary
wrote:
> Hi all, I am new to this list. Thanks for taking the time to read my
> questions! I just want to know if the data throughput I am seeing is expected
> for the bitcask backend or if it is too low.
>
> I am doing the preliminary fe
Resending to the list:
Ingo,
That is an indication that the protocol buffers server can't spawn a
put fsm, which means that a put cannot be done for some reason or
another. Are there any other messages that appear around this time
that might indicate why?
On Wed, Apr 3, 2013 at 12:09 AM
At the moment, the master branch of the python client is in a state of
flux leading up to another release. the 1.5-stable branch is more
likely what you want for the time being, or you can install from pypy
via pip or easy_install.
On Wed, Apr 3, 2013 at 6:02 AM, H. Ibrahim YILMAZ wrote:
> Hi,
Hi Evan,
I'm not sure, I find a lot of these:
2013-03-30 23:27:52.992 [error]
<0.8036.323>@riak_api_pb_server:handle_info:141 Unrecognized message
{22243034,{error,timeout}}
and some of these at the same time one of the kind below gets logged
(although the one has a different time stamp):
For your prior mail, I thought that someone had answered. Our initial
suggestion was to add +swt very_low to your vm.args, as well as
setting the +zdbbl setting that Jon recommended in the list post you
pointed to. If those help, moving to 1.3 should help more.
Other limits in vm.args that can c
Hi Evan,
I set swt very_low and zdbbl to 64MB, setting this params helped
reducing the busy_dist_port and Monitor got {suppressed,... Messages a
lot. But when the performance of the cluster suddenly drops we still see
these messages.
The cluster was updated to 1.3 in the meantime.
The eleve
I forgot to mention, we also sometimes see this one:
2013-04-03 17:04:08.551 [info] <0.56.0> alarm_handler:
{set,{system_memory_high_watermark,[]}}
(since Update to 1.3)
Ingo
Am 03.04.2013 17:03, schrieb Ingo Rockel:
Hi Evan,
I set swt very_low and zdbbl to 64MB, setting this params helped
Today the problem did *not* occur. This is the first time in a few weeks.
Turns out one of our internally-written modules, containing a fix for how
connections were utilized, got deployed.
Hopefully this has solved the problem.
Thanks for the help Evan!
--
Dave Brady
- Original Message -
Ingo,
riak-admin status | grep sys_process_count
will tell you how many processes are running. The default process
limit on erlang is a little low, and we'd suggest raising in
(especially with your extra-large ring_size). Erlang processes are
cheap, so 65535 or even double that will be fine.
Evan,
sys_process_count is somewhere between 5k and 11k on the nodes right
now. Concerning your suggested +P config, according to the erlang-docs,
the default for this param already is 262144, so setting it to 655536
would in fact lower it?
We chose the ring size to be able to handle growth
As for +P it's been raised in R16 (which is on the current man page)
on R15 it's only 32k.
The behavior that you're describing does sound like a very large
object getting put into the cluster (which may cause backups and push
you up against the process limit, could have caused scheduler collapse
o
We just had it again (around this time of the day we have our highest
user activity).
I will set +P to 131072 tomorrow, anything else I should check or change?
What about this memory-high-watermark which I get sporadically?
Ingo
Am 03.04.2013 17:57, schrieb Evan Vigil-McClanahan:
As for +P i
Again, all of these things are signs of large objects, so if you could
track the object_size stats on the cluster, I think that we might see
something. Even if you have no monitoring, a simple shell script
curling /stats/ on each node once a minute should do the job for a day
or two.
On Wed, Apr
Another engineer mentions that you posted your eleveldb section and I
totally missed it:
The eleveldb section:
%% eLevelDB Config
{eleveldb, [
{data_root, "/var/lib/riak/leveldb"},
{cache_size, 33554432},
{write_buffer_size_min, 67108864}, %% 64 MB in byte
How much data do you have in each partition? Are you running leveldb
or bitcask? If the former, what does your eleveldb config look like?
On Wed, Apr 3, 2013 at 6:26 AM, Giri Iyengar wrote:
> Evan,
>
> I tried re-introducing the TTL. It reverts back to the issue of vnodes not
> successfully tra
I'm wondering if we could get a 1.1.2 version bump pretty soon. Not being able
to do 2i over PBC with 1.1.1 is rather painful and I kind of need a released
version to send it to production.
Thanks,
Sean McKibben
On Jan 10, 2013, at 2:05 PM, Sean Cribbs wrote:
> Hey riak-users,
>
> Today we r
Can you clarify the problem you're having? That feature was merged in
July, long before the 1.1.0 release:
https://github.com/basho/riak-ruby-client/commit/4fe52756d7df6ee494bfbc40552ec017f3ff4da4
On Wed, Apr 3, 2013 at 3:35 PM, Sean McKibben wrote:
> I'm wondering if we could get a 1.1.2 version
You may wish to make the memory limit a little smaller; that means
~20GB per node, which might put undue memory pressure on leveldb.
I'd also recommend setting {max_open_files, 400} in the eleveldb
section (and maybe tuning the write buffer back down), as that's
important for high quantile latencie
IIRC it was fixed in 1.1.0 but came back in 1.1.1.
I did a simple test just now and sanitized it for this gist:
https://gist.github.com/graphex/5305274
I also have to store items with ? in their keys, which has issues over http
(noted in https://github.com/basho/riak-ruby-client/issues/80 )
So
Sure, I'll get a patch release out this week. I had forgotten about
that particular bug. Sorry for the inconvenience!
On Wed, Apr 3, 2013 at 4:07 PM, Sean McKibben wrote:
> IIRC it was fixed in 1.1.0 but came back in 1.1.1.
>
> I did a simple test just now and sanitized it for this gist:
> https:
Riak Users,
We are happy to announce that Riak 1.3.1 is ready for your to download and
install. It continues on the 1.3.x family with some nice bugfixes. See
the release notes linked below for all the details.
Release notes can be found here:
https://github.com/basho/riak/blob/1.3/RELEASE-NOTES
I hesitate to reply to my own email, but just wanted to point out that this
issue https://github.com/basho/riak_core/pull/281 listed in the release
notes should help all of you who had issues with slow bitcask startup times
in 1.3.0. If you see or don't see improvements let us know.
Thanks,
Jared
Hi,
I want to simulate a transaction.
I want to know when a riak operation happens.
I know that riak isn't a relational database, but it is important for me in
particular cases to undo operations when something goes wrong.
Any have any suggestion for me about I want to do?
Thank you very much.
Hi,
According to the docs at the following URL, it is necessary to reboot
all Riak nodes after setting the bucket property for backend.
This seems really drastic, and we'd like to avoid having to do this!
See:
http://docs.basho.com/riak/1.3.0/tutorials/choosing-a-backend/Multi/
I wondered if th
Hi,
Can we set Bitcask's expiry_secs value to be different per backend, in a
Multi-backend scenario?
Eg.
{multi_backend, [
{<<"bitcask_short_ttl">>, riak_kv_bitcask_backend, [
{expiry_secs, 3600}, %% Expire items after one hour
{expiry_grace_time, 600}
]},
{<
29 matches
Mail list logo
