Ошибка при параллельных инсертах

[Mikhail Petrov]

Привет.

Заливаю данные в табличку через cat one_file|clickhouse-client в 4 потока. Файлов много, размеры файлов - от 50 до 500Mb.

В один момент все клиенты отвалились. В логах каждого клиента:

Code: 209. DB::NetException: Timeout exceeded while reading from socket (10.240.0.6:9000): while receiving packet from 10.240.0.6:9000

В логах сервера ошибка только одна:

2016.11.09 01:17:18.577 [ 56 ] <Error> executeQuery: Code: 236, e.displayText() = DB::Exception: Cancelled merging parts, e.what() = DB::Exception (from ::ffff:10.240.0.7) (in query: INSERT INTO Requests (....skipped....) FORMAT TabSeparated), Stack trace:

0. clickhouse-server(StackTrace::StackTrace()+0x16) [0x10af806]

1. clickhouse-server(DB::Exception::Exception(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int)+0x1f) [0x107254f]

2. clickhouse-server(DB::MergeTreeDataMerger::mergePartsToTemporaryPart(std::vector<std::shared_ptr<DB::MergeTreeDataPart const>, std::allocator<std::shared_ptr<DB::MergeTreeDataPart const> > >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, DB::MergeListEntry&, unsigned long, long, DB::DiskSpaceMonitor::Reservation*)+0x1f59) [0x1232439]

3. clickhouse-server() [0x117c1dd]

4. clickhouse-server(DB::MergeTreeBlockOutputStream::writePrefix()+0x8a) [0x1187eca]

5. clickhouse-server(DB::TCPHandler::processInsertQuery(DB::Settings const&)+0x2fe) [0x1087c1e]

6. clickhouse-server(DB::TCPHandler::runImpl()+0x6c6) [0x10883c6]

7. clickhouse-server(DB::TCPHandler::run()+0x2b) [0x1088f7b]

8. clickhouse-server(Poco::Net::TCPServerConnection::start()+0xf) [0x2c1855f]

9. clickhouse-server(Poco::Net::TCPServerDispatcher::run()+0x14b) [0x2c3b93b]

10. clickhouse-server(Poco::PooledThread::run()+0xb7) [0x33d7fb7]

11. clickhouse-server(Poco::ThreadImpl::runnableEntry(void*)+0xa5) [0x33c74c5]

12. /lib/x86_64-linux-gnu/libpthread.so.0(+0x770a) [0x7f7dd53e570a]

13. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f7dd4a0682d]

Что это и как с этим можно бороться? Проблемы я вижу как минимум две:

1. Сама ошибка при конкурентных вставках.

2. Отсутствие ее обработки, выражающееся в прекращении общения с клиентом вместо отдачи какого-то кода ошибки.

Ну и, чтобы два раза не вставать - как регулируется потребление памяти при таких insert'ах? Вижу в show_processlist, что на указанных файликах (tsv в среднем 400Mb, пик до 700Mb) потребление памяти почти всегда доходит до 4Gb, а иногда и выше. Пару раз случался out of memory и обрыв запроса. Учитывается ли объем памяти, нужный для каких-то внутренних сортировок при insert, и влияют ли уже существующие данные на этот объем (проводится ли какое-то слияние с текущими данными непосредственно при запросе)? Есть ли какая-то четкая зависимость требуемой памяти вроде N*filesize?

[man...@gmail.com]

Привет.
В данный момент в сервере присутствует баг:

В случае, если вставка в таблицу типа MergeTree (не ReplicatedMergeTree) производится быстрее, чем выполняется процесс фоновых мерджей,
то при вставке инициируется внеочередной мердж. И при этом не контролируется количество таких внеочередных мерджей, из-за чего может быть израсходовано много памяти и слишком сильно нагружены диски.

Посмотреть количество таких внеочередных мерджей можно в
SELECT * FROM system.events WHERE event = 'SynchronousMergeOnInsert'

или по метрикам отправляемым в Графит - по пути ClickHouse.ProfileEvents.SynchronousMergeOnInsert

Если это число сильно больше нуля - значит проблема присутствует.

Также посмотрите на число одновременных мержей. Это
SELECT * FROM system.metrics WHERE metric = 'Merge'

или в Графите: ClickHouse.Metrics.Merge

Для того, чтобы обойти проблему, можно уменьшить количество потоков, вставляющих данные и, возможно, ограничить скорость вставки.

> Учитывается ли объем памяти, нужный для каких-то внутренних сортировок при insert, и влияют ли уже существующие данные на этот объем (проводится ли какое-то слияние с текущими данными непосредственно при запросе)?

И при INSERT и при мердже используется количество памяти, не зависящее от общего объёма данных и от общего количества вставляемых данных.
Излишний расход памяти возможен при слишком большом количестве одновременных мержей.

[madm1ke]

Примерно понял, спасибо.

При меньшем количестве потоков, действительно, все работает нормально. На 4 потоках у меня устойчиво воспроизводится через несколько десятков вставленных гигабайт.

А есть какие-то прогнозы по срокам исправления этого?

Хочу заметить, что в момент ошибки какой-то сверхъестественной нагрузки на сервере не было видно, и диски и проц - в пределах нормы. Собственно, суть описанного вами бага понятна, но почему при этом вылезла ошибка и отвалились все клиенты - не стало ясно...

10 ноября 2016 г., 4:30 пользователь <man...@gmail.com> написал:

--
You received this message because you are subscribed to the Google Groups "ClickHouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clickhouse+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/clickhouse/8ac71283-c49f-43cc-887a-16c41e405b86%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Mikhail U. Petrov.

[man...@gmail.com]

Клиенты отвалились по таймауту, так как они в течение этого таймаута (5 минут по-умолчанию) не смогли дождаться завершения синхронного мерджа.

Прогноз по исправлению - один из следующих релизов в течение двух-трёх недель.

[madm1ke]

Вдогонку пара замечаний по итогам случайного повторения этого race condition.

1. Кажется разумным поддержание коннекта в клиенте в таких случаях, хотя бы через условные "пинги" внутри коннекта. Запрос ведь продолжает работать.

2. Обнаружил интересное: делалась вставка в несколько потоков, и в результате данные в нескольких потоках реально не были вставлены, хотя ошибок к логах сервера нет. Клиенты, естественно, отвалились по таймауту.

То есть, в итоге запрос на insert не сработал, а в логах при этом пусто. Это кажется очень плохой ситуацией, безотносительно причин. Возможно, такое происходит еще в каких-то случаях.

 Если это важно - параллельно делается большой insert select, он продолжает корректно работать.

10 ноября 2016 г., 15:11 пользователь <man...@gmail.com> написал:

Клиенты отвалились по таймауту, так как они в течение этого таймаута (5 минут по-умолчанию) не смогли дождаться завершения синхронного мерджа.

Прогноз по исправлению - один из следующих релизов в течение двух-трёх недель.

--

You received this message because you are subscribed to the Google Groups "ClickHouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clickhouse+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/clickhouse/75b068de-6d43-4fdd-bb90-a1d1968cbd75%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Mikhail U. Petrov.

[man...@gmail.com]

Я как раз исправил эту ошибку. Сейчас это в тестинге.
Вы можете собрать версию из тега v1.1.54070-testing. Пакеты появятся позже.

[Stepan Semiokhin]

А у нас такой кейс: gzip-ованные данные загружаются с помощью web-интерфейса (с http-разархивацией, флагом enable_http_compression=1) через Distributed-таблицу в таблицы типа ReplicatedMergeTree.

Версия Кликхауса: 1.1.54083

Вопрос: во сколько потоков можно производить вставку данных, чтобы точно ничего не потерять и не получить проблемы с битыми данными?

пятница, 18 ноября 2016 г., 23:11:50 UTC+3 пользователь man...@gmail.com написал:

[madm1ke]

Судя по всему, сейчас - потоки можно не ограничивать.

13 декабря 2016 г., 16:39 пользователь Stepan Semiokhin <drs...@gmail.com> написал:

--

You received this message because you are subscribed to the Google Groups "ClickHouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clickhouse+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/clickhouse/c7da1d12-2c24-46ff-929a-735137454efc%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Mikhail U. Petrov.

[Stepan Semiokhin]

Ну вот у нас небольшой кластер из 8 машин, на каждом из которых загрузку можно пустить минимум в 16 потоков, т.е. 128 потоков, честно говоря, не представляю, что будет с кусками, которые появятся при вставке и должны мержиться, да еще отсортированно... Думаю, что лимит - потоков 8, поэтому и решил уточнить

вторник, 13 декабря 2016 г., 16:45:32 UTC+3 пользователь Mikhail Petrov написал:

Судя по всему, сейчас - потоки можно не ограничивать.

13 декабря 2016 г., 16:39 пользователь Stepan Semiokhin <drs...@gmail.com> написал:

А у нас такой кейс: gzip-ованные данные загружаются с помощью web-интерфейса (с http-разархивацией, флагом enable_http_compression=1) через Distributed-таблицу в таблицы типа ReplicatedMergeTree.

Версия Кликхауса: 1.1.54083

Вопрос: во сколько потоков можно производить вставку данных, чтобы точно ничего не потерять и не получить проблемы с битыми данными?

пятница, 18 ноября 2016 г., 23:11:50 UTC+3 пользователь man...@gmail.com написал:

Я как раз исправил эту ошибку. Сейчас это в тестинге.
Вы можете собрать версию из тега v1.1.54070-testing. Пакеты появятся позже.

--
You received this message because you are subscribed to the Google Groups "ClickHouse" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clickhouse+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/clickhouse/c7da1d12-2c24-46ff-929a-735137454efc%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Mikhail U. Petrov.

[man...@gmail.com]

Данные будут корректными. Но загрузка в столь большое количество потоков будет менее оптимальна. То есть, будет излишне нагружать сервер при той же скорости вставки.