я им трансферил виртуалки между дц

по 100 мбитному каналу

все выходные

нормальное

как его заставить утилизировать гигабит при rtt ~ 180-220 ms ?

по 100 мбитному каналу

ну сотка - это неинтересно.

ну может не на 100% эффективно использует канал

для домашнего использования бтсинк криповат

оно у меня максимум до 300 мбит разгонялось в локалке на гигабите

во всяком случае, был таковым, когда я его трогал

btsync - говно. медленное говно.

и микротик ненастроенный говно ?

и микротик ненастроенный говно ?

микротик любой говно.

я остановился на owncloud

это же вообще вебскрипт

на пхп

я им трансферил виртуалки между дц

Мммм, а VMware vCenter Converter Standalone Client не канает для твоих задачек?

я остановился на owncloud

как оно может быть шустрым?

как его заставить утилизировать гигабит при rtt ~ 180-220 ms ?

Спросить саппорт? :)

Мммм, а VMware vCenter Converter Standalone Client не канает для твоих задачек?

я такие слова впервые слышу, опиши что делают?

ещё раз: для домашнего использования =) Не виртуалки тягать, нет. Фотки, документики, видосы- легко

и всякие провайдерские dpi не мешают жить

я такие слова впервые слышу, опиши что делают?

натравливаешь на одну машину, потом на другой сервер и он туда кладет целиком машину с конфигами и т.п.

почему в польше7

Пальцем в глобус ткнул

натравливаешь на одну машину, потом на другой сервер и он туда кладет целиком машину с конфигами и т.п.

ну сервера между собойн напрямую кидают ?

ту виртуалку

Спросить саппорт? :)

Роман и так знает ответ. Я вот тоже знаю

ну сервера между собойн напрямую кидают ?

данусчегобы, через ту машину, на которой конввертер )

Роман и так знает ответ. Я вот тоже знаю

а я знаю, что моно получить больше :)

В один поток не выйдет :)

данусчегобы, через ту машину, на которой конввертер )

отличненько так, то есть в итоге даже не сотка была а меньше Ж(

отличненько так, то есть в итоге даже не сотка была а меньше Ж(

Dci на сто мбит?

ну так на одном из серверов машину с виндой подними и там запускай конвертор, в чем проблема то? :)

Dci на сто мбит?

мини дц по городу (сервера под столами)

мини дц по городу (сервера под столами)

Типа утром бухгалтер пришла, включила сервак и виртуалки перебалансировались?)

Огонь

Не просто миграция виртуалок с одной ноды на другую в другом офисе для профилактических работ на первой

Скучно

Не просто миграция виртуалок с одной ноды на другую в другом офисе для профилактических работ на первой

А встроенного механизма у vspere разве нет?

У меня квм там.

И ноды не в кластере

Часто для миграции надо шаред сторадж

И ноды не в кластере

Ну вот сделай себе везде Л2 среду и таскай их централизованно без остановки сервиса )

Стораджейй отдельных нет кроме бекапа. Л2 и так есть на микротик еоип

Всём добра! Вводные: несколько процессов слушают по несколько tcp портов, подключения постоянны, linux 4.4.40, fs.nr_open = 1048576, fs.file-max = 52705442, ну и другие лимиты выручены выше 65535, однако: # conntrackd -s cache stats: current active connections: 65534 connections created: 2714346 failed: 22232901 connections updated: 10859059 failed: 0 connections destroyed: 2648812 failed: 0 Как сиё следует интерпретировать?

Всём добра! Вводные: несколько процессов слушают по несколько tcp портов, подключения постоянны, linux 4.4.40, fs.nr_open = 1048576, fs.file-max = 52705442, ну и другие лимиты выручены выше 65535, однако: # conntrackd -s cache stats: current active connections: 65534 connections created: 2714346 failed: 22232901 connections updated: 10859059 failed: 0 connections destroyed: 2648812 failed: 0 Как сиё следует интерпретировать?

sysctl net.netfilter.nf_conntrack_max покажите :)

net.netfilter.nf_conntrack_max = 1048576

net.netfilter.nf_conntrack_count = 150565

ну где-то же ограничивается

Из того, для чего установлено ограничение в ~65535 fs.overflowgid = 65534 fs.overflowuid = 65534 kernel.ngroups_max = 65536 kernel.overflowgid = 65534 kernel.overflowuid = 65534 net.ipv6.conf.lo.mtu = 65536 sunrpc.tcp_max_slot_table_entries = 65536 vm.max_map_count = 65530 vm.mmap_min_addr = 65536

как вариант: conntrackd -s кажет ересь (надо лезть в сорцы, лениво), но а если нет...

Может дело в ulimit?

поднят естественно.

Или выкручено?

Пичаль

а сервис системд запускаеться ?

а сервис системд запускаеться ?

нет

процессов несколько (20), на каждом следующие параметры: prlimit —pid 3362 RESOURCE DESCRIPTION SOFT HARD UNITS AS address space limit unlimited unlimited bytes CORE max core file size 0 unlimited blocks CPU CPU time unlimited unlimited seconds DATA max data size unlimited unlimited bytes FSIZE max file size unlimited unlimited blocks LOCKS max number of file locks held unlimited unlimited MEMLOCK max locked-in-memory address space 65536 65536 bytes MSGQUEUE max bytes in POSIX mqueues 819200 819200 bytes NICE max nice prio allowed to raise 0 0 NOFILE max number of open files 128000 128000 NPROC max number of processes 2063466 2063466 RSS max resident set size unlimited unlimited pages RTPRIO max real-time priority 0 0 RTTIME timeout for real-time tasks unlimited unlimited microsecs SIGPENDING max number of pending signals 2063466 2063466 STACK max stack size 8388608 unlimited bytes

а что strace пишет

да и подключений по портам или по sock файлам посчитать - то их суммарно около того же значения что и в net.netfilter.nf_conntrack_count. что же кажет conntrackd -s - не ясно.

Всём добра! Вводные: несколько процессов слушают по несколько tcp портов, подключения постоянны, linux 4.4.40, fs.nr_open = 1048576, fs.file-max = 52705442, ну и другие лимиты выручены выше 65535, однако: # conntrackd -s cache stats: current active connections: 65534 connections created: 2714346 failed: 22232901 connections updated: 10859059 failed: 0 connections destroyed: 2648812 failed: 0 Как сиё следует интерпретировать?

Зачем вам conntrackd?

есть кое-какие проблемы в работе приложения, пытаюсь разобраться, применяют инструменты.

да и подключений по портам или по sock файлам посчитать - то их суммарно около того же значения что и в net.netfilter.nf_conntrack_count. что же кажет conntrackd -s - не ясно.

покажи conntrack -S

а conntrackd на фиг не нужен, если только не используете кластер для файерволлов или юзерспейсные хелперы.

а conntrackd на фиг не нужен, если только не используете кластер для файерволлов или юзерспейсные хелперы.

И хер его знает что он там нафейлил. Это статистика не контрека а демона...

это именно статистика кэша соединений самого conntrackd, а не таблица коннтрака.

есть кое-какие проблемы в работе приложения, пытаюсь разобраться, применяют инструменты.

Если это был мне ответ - то вы хреновый инструмент выбрали.

покажи conntrack -S

https://paste.ubuntu.com/24139628/ - но как я понял это устаревшая опция.

ERROR: S client not available

нет, неправильно понимаешь.

Опять линукс-чатик?

а странная статистика в выводе conntrackd -s из-за дефолтного конфига - # # Maximum number of conntracks: # it must be >= $ cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max # HashLimit 65535

Даже для меня здесь сейчас происходит магия...

Коннтраки помнится в /proc смотрел.. посчитайте там количество записей просто

wc -l

conntrack -c

если хочешь просто количество сессий в коннтраке, то делаешь conntrack -C

Alibek вырубай conntrackd, если ты действительно его не используешь. Ещё странно то, что у тебя такое гигантское количество cpu в выводе conntrack -S - это общая статистика внутренней работы conntrack-а. Но пока там нет ненулевых insert_failed, то беспокоиться нет причин.

а странная статистика в выводе conntrackd -s из-за дефолтного конфига - # # Maximum number of conntracks: # it must be >= $ cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max # HashLimit 65535

бляхомухо а я мимо глядел, думал оно на основании net.netfilter.nf_conntrack_buckets берёт

nf_conntrack_buckets и nf_conntrack_max - это разные штуки. buckets - это количество ячеек в хэш-таблице коннтрака, а conntrack_max - это максимальное количество записей. В одной ячейке (bucket-e) может лежать несколько записей (коллизия хэш-таблицы).

я бы ещё на твоём месте подтюнил бы таймеры - дефолтное время жизни коннтрак-записи о tcp-коннекте - 5 суток.

я это знаю, фокус в том что в последних ядрах эти знанчения автоматом расчитываются и те воркераунды что были ранее (типа wmem увелчить и т.п.) не применимы.

время жизни - выставлено в 7875 сек

ну это всегда рассчитывалось автоматом в зависимости от объёма памяти.

http://lxr.free-electrons.com/source/net/netfilter/nf_conntrack_core.c?v=4.7#L1713

на апрельской конференции netdev будет большой workshop по conntrack-у и обсуждение дальнейшего его развития.

ок, спасибо за науку

кстати, есть не особо известная фича под названием conntrack timeout extension - разным типам трафика можно присвоить разные таймауты коннтрак-записей. где-то в мэйл-листе netfilter-dev было подробное обсуждение его применения.

А еще лучше реальники ?

Сколько под одним адресом народа выпускаете?

https://www.spinics.net/lists/netfilter/msg57099.html

Сколько под одним адресом народа выпускаете?

у меня кейс не выпускать, а впускать.

?

у меня кейс не выпускать, а впускать.

А контрек вам вообще зачем? :)))

всех впускать, никого не выпускать)

А контрек вам вообще зачем? :)))

чисто для статистики ;) а так есть схема предварительной маршрутизацией на базе netfilter с -m statistic —mode random —probability

И после этого говорят, что микротиковцы извращенцы... Ну-ну...

микротик нам бы только головной боли добавил.

схема действительно какая-то адовая)

чисто для статистики ;) а так есть схема предварительной маршрутизацией на базе netfilter с -m statistic —mode random —probability

а дальше то что?

схема действительно какая-то адовая)

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