; improvement.
>>
>> As a general/meta statement, Cassandra is very multi-threaded, and
>> consumes file handles like crazy. How many different query cases do you
>> really want to put on one cluster/node? ;D
>>
>> =Rob
>>
>>
>
--
Nikolai Grigoriev
(514) 772-5178
.c.fs-staging.internal", "num_procs": 1,
> "streaming": {}, "token": "6048217978730786970", "data_held": 54319361.0,
> "mode": "normal", "rpc_ip": "10.240.111.79", "partitions": {"saved_caches":
> "/dev/sdb", "commitlog": "/dev/sdb", "other":
> ["/dev/disk/by_uuid/2795e34f_4e9b_46a9_9e39_e6cc0f1f1478", "rootfs"],
> "data": ["/dev/sdb"]}, "os": "linux", "rack": "a", "last_seen": 0},
> {"load": 0.04, "has_jna": false, "vnodes": true, "devices":
> {"saved_caches": "sdb", "commitlog": "sdb", "other": ["sda"], "data":
> ["sdb"]}, "task_progress": {}, "node_ip": "10.240.129.185",
> "network_interfaces": ["eth0", "lo"], "ec2": {"instance-type": null,
> "placement": null, "ami-id": null, "instance-id": null}, "node_version":
> {"search": null, "jobtracker": null, "tasktracker": null, "spark":
> {"master": null, "version": null, "worker": null}, "dse": null,
> "cassandra": "2.0.9"}, "dc": "us-central1", "node_name":
> "cassandra-db-2.c.fs-staging.internal", "num_procs": 1, "streaming": {},
> "token": "4393271482730462700", "data_held": 51388793.0, "mode": "normal",
> "rpc_ip": "10.240.129.185", "partitions": {"saved_caches": "/dev/sdb",
> "commitlog": "/dev/sdb", "other":
> ["/dev/disk/by_uuid/2795e34f_4e9b_46a9_9e39_e6cc0f1f1478", "rootfs"],
> "data": ["/dev/sdb"]}, "os": "linux", "rack": "b", "last_seen": 0}]
>
--
Nikolai Grigoriev
(514) 772-5178
le+ profile
> <https://plus.google.com/102718274791889610666/posts>
> <http://spinn3r.com>
>
>
--
Nikolai Grigoriev
(514) 772-5178
gt;> Increasing the size of sstables might help if you have enough CPU and
> you
> >> can put more load on your I/O system (@Andrei, I am interested by the
> >> results of your experimentation about large sstable files)
> >>
> >> From my point of view,
s
> there a rule of thumb for the maximum number of concurrent asynchronous
> queries I should execute?=
>
--
Nikolai Grigoriev
(514) 772-5178
re some usage patterns where it is better to
> have many small servers than a few large servers. Probably, it is better to
> have many small servers if you need LCS for large tables.
>
> Just my 2 cents.
>
> Jean-Armel
>
> 2014-11-24 19:56 GMT+01:00 Robert Coli :
>
>>
coding
level but obvious benefits without extra operational complexity.
On Mon, Nov 24, 2014 at 9:32 AM, Andrei Ivanov wrote:
> Nikolai,
>
> This is more or less what I'm seeing on my cluster then. Trying to
> switch to bigger sstables right now (1Gb)
>
> On Mon, Nov
Andrei,
Oh, Monday mornings...Tb :)
On Mon, Nov 24, 2014 at 9:12 AM, Andrei Ivanov wrote:
> Nikolai,
>
> Are you sure about 1.26Gb? Like it doesn't look right - 5195 tables
> with 256Mb table size...
>
> Andrei
>
> On Mon, Nov 24, 2014 at 5:09 PM, Nikolai Grigo
e :
>
>> Hi Nikolai,
>>
>> Thanks for those informations.
>>
>> Please could you clarify a little bit what you call "
>>
>> 2014-11-24 4:37 GMT+01:00 Nikolai Grigoriev :
>>
>>> Just to clarify - when I was talking about the large amount o
> strategy the same thing may happen. This is all due to limitations
> mentioned by Nikolai.
>
> Andrei,
>
>
> On Sun, Nov 23, 2014 at 8:51 AM, Servando Muñoz G.
> wrote:
> > ABUSE
> >
> >
> >
> > YA NO QUIERO MAS MAILS SOY DE MEXICO
> &
t performance is fine, for both writes and reads..
> - Currently using SizedCompactionStrategy
>
> We're trying to limit the amount of storage used during compaction. Should
> we switch to LeveledCompactionStrategy?
>
> Thanks
>
--
Nikolai Grigoriev
(514) 772-5178
numbers are so high. Have others noticed this behavior? How much
> context switching is expected and why? What are the variables that affect
> this?
>
>
>
> /J
>
--
Nikolai Grigoriev
(514) 772-5178
itch: false".
>
> On Thu, Nov 20, 2014 at 9:52 AM, Nikolai Grigoriev
> wrote:
>
>> Hi,
>>
>> There is something odd I have observed when testing a configuration with
>> two DC for the first time. I wanted to do a simple functional test to prove
>> mys
e used with vanilla Apache Cassandra, but I
> have never actually tried to do so.
>
> =Rob
>
>
--
Nikolai Grigoriev
(514) 772-5178
bly
the list with equal proximity should be shuffled randomly? Or, instead of
picking the first target, a random one should be picked?
--
Nikolai Grigoriev
15 matches
Mail list logo