Я использую LevelDB в моем приложении с 5 базами данных. Каждая база данных открывается с опцией max_open_files = 64
,
ulimit -Sn
показывает, что операционная система имеет ограничение в 1024 файла. Установка ограничения на 2048 устраняет проблему. Поскольку я распространяю это приложение среди людей, оно должно иметь настройки по умолчанию, которые не требуют настройки людьми для настройки их операционной системы.
leveldb::Status status = db_spends_->Get(
leveldb::ReadOptions(), spent_slice, &raw_spend);
if (!status.ok())
{
std::cerr << "fetch_spend: " << status.ToString() << std::endl;
return false;
}
Я получаю много этих ошибок и не могу читать вообще.
"fetch_spend: IO error: XXXX.sst: Too many open files"
В одном подкаталоге находится 5 баз данных database
:
$ ls
addr block block_hash spend tx
$ du -sh .
16G .
$ du -sh *
2.6G addr
653M block
7.2M block_hash
2.6G spend
9.4G tx
$ for i in `ls`; do echo $i; ls $i | wc -l; done
addr
1279
block
333
block_hash
10
spend
1433
tx
5252
Я хотел бы изменить ограничение в 2 МБ внутри LevelDB для каждого файла .sst, но это не похоже на изменение, и я видел только этот патч в Google: https://github.com/basho/leveldb/pull/7
Я использую Ubuntu 13.04 64bit.
Вот код, который я использую для открытия баз данных. Если я покажу open_options.max_open_files
до звонка leveldb::DB::Open()
, он отображает 64 (как и ожидалось).
bool open_db(const std::string& prefix, const std::string& db_name,
std::unique_ptr<leveldb::DB>& db, leveldb::Options open_options)
{
using boost::filesystem::path;
path db_path = path(prefix) / db_name;
leveldb::DB* db_base_ptr = nullptr;
leveldb::Status status =
leveldb::DB::Open(open_options, db_path.native(), &db_base_ptr);
if (!status.ok())
{
log_fatal(LOG_BLOCKCHAIN) << "Internal error opening '"<< db_name << "' database: " << status.ToString();
return false;
}
// The cointainer ensures db_base_ptr is now managed.
db.reset(db_base_ptr);
return true;
}
...
// Create comparator for blocks database.
depth_comparator_.reset(new depth_comparator);
// Open LevelDB databases
const size_t cache_size = 1 << 20;
// block_cache, filter_policy and comparator must be deleted after use!
open_options_.block_cache = leveldb::NewLRUCache(cache_size / 2);
open_options_.write_buffer_size = cache_size / 4;
open_options_.filter_policy = leveldb::NewBloomFilterPolicy(10);
open_options_.compression = leveldb::kNoCompression;
open_options_.max_open_files = 64;
open_options_.create_if_missing = true;
// The blocks database options needs its depth comparator too.
leveldb::Options blocks_open_options = open_options_;
blocks_open_options.comparator = depth_comparator_.get();
if (!open_db(prefix, "block", db_blocks_, blocks_open_options))
return false;
if (!open_db(prefix, "block_hash", db_blocks_hash_, open_options_))
return false;
if (!open_db(prefix, "tx", db_txs_, open_options_))
return false;
if (!open_db(prefix, "spend", db_spends_, open_options_))
return false;
if (!open_db(prefix, "addr", db_address_, open_options_))
return false;
Даже если я поставлю max_open_files = 20
У меня все та же проблема.
До недавнего времени могло быть некоторое патологическое поведение, когда max_option_files был установлен в < 74, где вместо описанных опций использовались сотни файловых дескрипторов. (В последней версии зажимов leveldb предел составляет 74.) Имеет ли значение ~ 80 какое-либо влияние? Если нет, и у вас все еще есть проблема, могли бы вы запустить соответствующее заклинание lsof, когда вы видите плохое поведение? Это скажет нам, куда идут файловые дескрипторы.
Других решений пока нет …