Hi, Satish. OS X's implementation of poll(3) has a known limitation of
1024 file descriptors, if I recall correctly. If you don't have "+K
true" in vm.args (or cuttlefish equivalent, sorry, I don't have it handy
right now), then please use that flag to bypass some libc (?) brokenness.
-Scott
__
Hi, Jason. Have you tried using the system inspection utilities bundled
with Riak?
http://docs.basho.com/riak/latest/ops/running/tools/riak-admin/#top
http://docs.basho.com/riak/latest/ops/running/tools/riak-admin/#cluster-info
http://docs.basho.com/riak/latest/ops/upgrading/production-checklist/
Hi, Bryan, sorry to jump in so late. Have you tried this?
webtool:start().
Webtool has a non-native-GUI version of the CrashDumpViewer: load
http://127.0.0.1:/ in a local web browser, then start the
CrashDumpViewer, then load the dump file, then browse.
-Scott
_
Oleksiy Krivoshey wrote:
ok> Thanks! What kind of negative impact can the NIF mode cause on
ok> Bitcask?
Please see the "Long-running NIFs" section of
http://www.erlang.org/doc/man/erl_nif.html ... and NIF execution blocks
the Erlang scheduler thread until the NIF is finished.
-Scott
Oops, sorry, I overlooked your question. The erlang/nif I/O setting
affect all Bitcask file I/O, see
https://github.com/basho/bitcask/blob/develop/src/bitcask_io.erl
-Scott
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/m
raghwani sohil wrote:
rs> It means key k1 and k3 becomes dead keys Right ?
Correct.
-Scott
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
raghwani sohil wrote:
rs> what is meaning of "keys that are no longer the latest value" ?
Keys that have been overwritten with a newer value.
-Scott
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-u
Sargun Dhillon wrote:
sd> Can you run: [...]
Hi, Sargun and Oleksiy. Those commands and a lot more are run as part
of the suite of info-gathering done by the "riak-debug" utility. I
recommend using it instead of managing a hodge-podge of separate
commands.
The output from "riak-admin cluster-
Tom Santero wrote:
ts> Can we expect a 2.0.1 release forthcoming? I was planning on
ts> upgrading Riak today to 2.0, but since I use Bticask I'm affected by
ts> this. I'd prefer not to upgrade to 2.0 in production until this is
ts> patched and packaged in a proper release.
Hiya, Tom. I'm not su
Tom Santero wrote:
ts> Can we expect a 2.0.1 release forthcoming? I was planning on
ts> upgrading Riak today to 2.0, but since I use Bticask I'm affected by
ts> this. I'd prefer not to upgrade to 2.0 in production until this is
ts> patched and packaged in a proper release.
Hiya, Tom. I'm not su
Toby Corkindale wrote:
tc> So basho_bench creates keys that
tc> can't be manipulated by anything except erlang :/ You can delete
tc> them if you write some erlang though.. -Toby
You're correct, though you can also configure basho_bench to string-ify
the integers that are used as keys. Use eith
Hi, Mahesh. I didn't see a reply to your question, but my email server
was down for a while, so perhaps I missed it.
There are several ways to manipulate Erlang/OTP's code server's
configuration (similar in spirit to the Java CLASSPATH). See the "-pz"
(recommended) and "-pa" flags in http://www.
Edgar Veiga wrote:
ev> Is this normal?
Yes. One or more of your vnodes can't keep up with the workload
generated by AAE repair or a vnode can't keep up for another
reason, and AAE repair shouldn't actively make things worse.
The logging is done by:
https://github.com/basho/riak_kv/blob/1
Andre Lohmann wrote:
al> When Hitting Server 1 again for the same file, will it be fetched
al> again piece by piece from the other servers, or is there some kind
al> of caching (prefered in memory) available, to deliver this file from
al> cache the next time?
Riak CS does not have such a caching
Denis Zhdanov wrote:
dz> Hi All, Could someone answer is basho_bench's
dz> basho_bench_driver_http_raw driver working or not now?
Hi. Yes, it works fine ... but does not support the 'delete' operation
that you're trying to use in your config's 'operation' list.
-Scott
Kevin Burton wrote:
kb> I replaced the 127.0.0.1 with the address for my cluster (I have 4
kb> nodes in the cluster). I get an error: `[info] can't set long node
kb> name Please check configuration' followed by a fatal error [error]
kb> Failed to start net kernel.
Kevin, what arguments did you
Wu Ray wrote:
wr> Thanks. what's more, I want to know if there is best practice for
wr> performance in this special situation, such as avoiding to do
wr> something, etc.
With Riak right now, the best choice is to avoid arbitrary bucket names
and use a small (or one) bucket that can support the b
Will Hutchinson wrote:
wh> Hi, we are using riak_core and our own custom vnode type (call it
wh> foo) that implements the riak_core_vnode behaviour. [...]
Will, have you tried riak_core:wait_for_service(Service)? Note that
that function will only wait for vnodes on the local node and not vnodes
>>> "ar" == Armon Dadgar wrote:
ar> All the nodes appeared to have been blocked trying to talk to riak
ar> 001 which was the ring claimant at the time. Doing this seems to
ar> have cleared the state enough for the cluster to make progress
ar> again.
Armon, it's quite unlikely that the ring claim
Sorry about the late reply.
> "tb" == thomas bikeev writes:
tb> Oops, actually I do get the following in the monitor: Does it mean
tb> that loose consistency because of low mem / resources?
tb> 14:21:00.395 [info] monitor long_gc <0.13156.5>
[{initial_call,{riak_core_vnode_worker_pool,init
Tomer Naor wrote:
tn> riak start
tn> Attempting to restart script through sudo -u riak
tn> pthread/ethr_event.c:98: Fatal error in wait__(): Function not
tn> implemented (38)
tn> pthread/ethr_event.c:98: Fatal error in wait__(): Function not
tn> implemented (38)
Tomer, those are new to me. Y
Elias Levy wrote:
el> Please correct me if I am wrong, but after
el> reading the documentation and looking at a test system, it appears
el> that by default Riak will store data from different buckets within
el> the same backend. That it merely treats the bucket as a prefix to
el> the key and as
Jonathan Langevin wrote:
jl> Even for development-purposes only? Otherwise it seems data would be
jl> written n times to the same machine, which is needless in a dev
jl> environment with low storage specs...
... which would be true until the 1-node cluster grows to a 2-node or
N-node cluster. C
David Koblas wrote:
dk> * innostore section - {flush_method, "O_DIRECT"}
David, what happens when you remove that option and allow the default to
be used?
-Scott
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/li
Jeff Pollard wrote:
jp> Overnight we do some data collection that is stored in Riak, and
jp> just last night we had one of our server's load spike very high and
jp> just drop back down to more acceptable levels. You can see a graph
jp> of it [1]here.
Jeff, all that load average tells you is a w
gtuhl wrote:
> With Riak, my main challenge is getting this data loaded. Using the
> PHP library I am able to push 100-200 documents/sec.
A quick grep through the PHP client source suggests that that client
doesn't support the Protocol Buffers interface to Riak. Depending on
the workload, a
Dimitry, you didn't include any server log messages in your email. I'm
not very familiar with the Protocol Buffers service, but it's likely
that it's logging an error when closing your connection. Or, if it's
the client that's disconnecting (though I dunno why it'd do that), then
the server may a
Anthony, I shouldn't reply to email in the morning before coffee, but
here's to risking looking silly
The SASL "PROGRESS REPORT" messages are SASL messages and thus are
written to where the sasl_error_logger attributes says to write them.
Messages from a generic error_logger:error_msg/info_msg
James Linder wrote:
jl> I am getting inconsistent results using the Riak Search Solr
jl> interface. Specifically, the number of results and ordering of
jl> results is changing from one query to the next.
jl> [...]
jl> - We are running riak-search-0.14.0-1.el5 installed via the Basho
jl> provided
Nicolas Fouché wrote:
nf> [...] But when I look at the props of a bucket, r,w,dw and rw are present
nf> twice :
nf> [...]
nf> I use riak search 0.14.0. Bug ?
Feature. Erlang property lists take the first element in the list that
matches the property name.
On the other hand, I don't know what
Joshua Partogi wrote:
jp> I tried to look for Riak API for getting clusters information on the
jp> wiki with no luck. Is there any API in Riak for getting the number
jp> of node involved and alive/dead in the cluster?
Joshua, the exported functions in riak_core_ring.erl are probably what
you're
Nathan Sobo wrote:
ns> Is a key-value store actually inappropriate for this problem?
No. One way to do it is to use a single KV key to store multiple
addresses worth of info. Pick a relatively big number, 50K
subscribers/key, though it may vary. Use a key naming scheme so that
you can pre-cal
Ulf Wiger wrote:
uw> Actually, in general, you _should_ leave it running, as other
uw> applications on your system may depend on it.
Ulf is right: you ought to leave it running. The protocol is stable, so
beyond the very rare bugfix, there's no epmd-was-upgraded-now-what
reason to kill it.
Kil
Catching up(*) on a thread from the end of October (nothing like being
prompt, is there?)...
Charles Blair wrote:
cb> Thanks for spotting the "brainos". But even without those, here is a
cb> repeat of the experiment.
Assuming that these code snippets demonstrate what you're trying to do,
then I
Nico Meyer wrote:
nm> I discovered another problem while debugging this. I you restart (or
nm> it crashes) a node that you removed from the cluster which still has
nm> data, it won't start handing off it's data afterwards. The reason
nm> being, that is the node watcher also does not get notified
Charles Blair wrote:
cb> In step 2 I can retrieve a key whose value is a string. In step 3, I
cb> fail to retrieve the value.
The good news: you did fetch it.
The bad news: immediately afterward Erlang's pattern matching failed
which threw an exception which killed the shell/CLI process that
36 matches
Mail list logo
