On Fri, Feb 24, 2017 at 12:39 PM, Adar Dembo wrote:
> It's definitely safe to increase the ulimit for open files; we
> typically test with higher values (like 32K or 64K). We don't use
> select(2) directly; any fd polling in Kudu is done via libev which I
> believe uses epoll(2) under the hood. T
I think range partitioning is a fine solution for your use case,
though you should know that we're not recommending more than 4 TB of
total data (post-encoding/compression) per tserver at the moment. I
don't expect anything to break outright if you exceed that, but
startup will get slower and slowe
I'm using the debs from the cloudera-kudu ppa with little change to the
default configuration, so one master and one tablet server. I set
num_replicas(1) when creating each table. I used range partitioning with
(if I understand correctly) one large open-ended range. So that should
have 334 table
Hi Paul,
As you discovered, Kudu holds WAL segments open until the tablets they
belong to are deleted. block_manager_max_open_files won't help here;
that just applies to files opened for accessing data blocks, not WAL
segments.
As far as WAL segments are concerned, we've previously discussed
"que
I wrote a quick script today to see how kudu behaves if I create many
tables. After creating 334 tables, I started getting timeouts. I see this
in the master log file:
W0216 11:37:48.961221 49810 catalog_manager.cc:2490] CreateTablet RPC for
tablet 9b259d5c5ff74f04820240f2159bc1a0 on TS
faaf4e9b
