|
|
|
stаlkerok
Стаж: 1 год 9 месяцев Сообщений: 1818
|
stаlkerok ·
01-Фев-24 19:04
(9 месяцев назад)
Hanabishi писал(а):
85819881Либо же в libtorrent как-то очень неправильно UDP сокеты настроены, в чем я сомневаюсь.
Я видел как кто-то жаловался на uTP в libtorrent, и не один раз, сейчас не могу найти. Там пользователь сравнивал с uTP в uTorrent. Надо будет ещё в нём потестить и найти те комменты пользователя, там тоже была интересная инфа.
|
|
|
|
Биомеханик
Стаж: 17 лет 5 месяцев Сообщений: 9322
|
Биомеханик ·
01-Фев-24 19:08
(спустя 3 мин.)
stаlkerok писал(а):
85819943Там пользователь сравнивал с uTP в uTorrent.
Poor uTP performance #3542
|
|
|
|
stаlkerok
Стаж: 1 год 9 месяцев Сообщений: 1818
|
stаlkerok ·
01-Фев-24 19:15
(спустя 7 мин., ред. 01-Фев-24 19:15)
Биомеханик, да, вроде бы оно. И да, пользователь это Seeker2.
|
|
|
|
Hanabishi
Стаж: 14 лет 7 месяцев Сообщений: 2897
|
Hanabishi ·
01-Фев-24 20:15
(спустя 1 час, ред. 01-Фев-24 20:16)
Решил все же потестить 1.2.
stаlkerok писал(а):
85819104Разница между отключенным кэшем диска и кэшем 512 МБ
А вот это у меня не подтверждается. С кэшем даже наоборот медленнее.
Сдается мне все же у тебя с дисками что-то не то, либо таки виндовое окружение гадит 
Вот еще до кучи результаты с 2.0. Относительно 1 версии печальные, хоть и более чем достаточные для гигабита конечно.
На скриншотах MMAP и POSIX соответственно.
Особенно радует "стабильность" графиков 
|
|
|
|
stаlkerok
Стаж: 1 год 9 месяцев Сообщений: 1818
|
stаlkerok ·
01-Фев-24 20:45
(спустя 29 мин., ред. 01-Фев-24 20:45)
Hanabishi писал(а):
85820191А вот это у меня не подтверждается. С кэшем даже наоборот медленнее.
Сдается мне все же у тебя с дисками что-то не то, либо таки виндовое окружение гадит
Такие результаты можно получить в пределах одного SSD, и все равно с кэшем лучше, вряд ли это SSD или система влияют (SSD с DRAM кэшем). Мне не удалось сравнять скорость с кэшем и без, сразу видно, где на графике без кэша.
ps. в клиентах одинаковые настройки, то бишь кэш отключается в обоих клиентах.
|
|
|
|
Hanabishi
Стаж: 14 лет 7 месяцев Сообщений: 2897
|
Hanabishi ·
01-Фев-24 20:47
(спустя 1 мин.)
stаlkerok писал(а):
85820410Такие результаты можно получить в пределах одного SSD
У меня на принимающей стороне рамдиск использовался, чтобы точно не портить результаты скоростью записи. Так как мы здесь сидирование тестируем.
|
|
|
|
stаlkerok
Стаж: 1 год 9 месяцев Сообщений: 1818
|
stаlkerok ·
01-Фев-24 20:51
(спустя 4 мин.)
Hanabishi писал(а):
85820476У меня на принимающей стороне рамдиск использовался
Я их больше никогда юзать не буду)
|
|
|
|
Hanabishi
Стаж: 14 лет 7 месяцев Сообщений: 2897
|
Hanabishi ·
01-Фев-24 21:30
(спустя 39 мин., ред. 01-Фев-24 21:33)
Вот еще чтение с внешнего HDD потестил. Скрины 0 и 512 кэша соответственно.
Тут как ни странно разницы нет вообще никакой можно сказать, вопреки моему ожиданию.
Возможно HDD просядет без кэша в ситуации когда одновременно раздается сразу много раздач. Но такой сценарий сложно протестить искусственно.
stаlkerok писал(а):
85820493Я их больше никогда юзать не буду)
Ну в линуксах это сводится просто к закачке в /tmp, так как она почти везде в оперативу смонтирована по дефолту.
|
|
|
|
GCRaistlin
Стаж: 16 лет 10 месяцев Сообщений: 5770
|
GCRaistlin ·
01-Фев-24 21:55
(спустя 25 мин.)
Hanabishi писал(а):
85820683Возможно HDD просядет без кэша в ситуации когда одновременно раздается сразу много раздач.
Что вы имеете в виду под "просядет"?
|
|
|
|
Hanabishi
Стаж: 14 лет 7 месяцев Сообщений: 2897
|
Hanabishi ·
01-Фев-24 22:06
(спустя 10 мин.)
GCRaistlin писал(а):
85820819Что вы имеете в виду под "просядет"?
Упадет скорость из-за большой очереди запросов. По идее график будет напоминать пилу из-за задержек в чтении. Вопрос - помогает ли кэш клиента сгладить ситуацию.
|
|
|
|
stаlkerok
Стаж: 1 год 9 месяцев Сообщений: 1818
|
stаlkerok ·
01-Фев-24 22:18
(спустя 12 мин.)
Hanabishi, помогает, я как нибудь на сервере с популярной раздачей проведу тест, при скорости 100МБ/с отключу кэш.
|
|
|
|
GCRaistlin
Стаж: 16 лет 10 месяцев Сообщений: 5770
|
GCRaistlin ·
01-Фев-24 22:25
(спустя 6 мин.)
Hanabishi писал(а):
85820881Упадет скорость из-за большой очереди запросов.
С чего бы ей упасть? HDD как отдавал на максимуме своих возможностей, так и будет отдавать.
|
|
|
|
stаlkerok
Стаж: 1 год 9 месяцев Сообщений: 1818
|
stаlkerok ·
01-Фев-24 22:29
(спустя 4 мин.)
GCRaistlin, с HDD можно легко раздавать на скорости 100МБ/с, но небольшому количеству пиров.
|
|
|
|
Hanabishi
Стаж: 14 лет 7 месяцев Сообщений: 2897
|
Hanabishi ·
01-Фев-24 22:48
(спустя 18 мин.)
GCRaistlin писал(а):
85820987С чего бы ей упасть?
Почитайте о принципах работы HDD и почему им нужна дефрагментация. И в чем их отличие от SSD, которым дефрагментация не нужна.
|
|
|
|
GCRaistlin
Стаж: 16 лет 10 месяцев Сообщений: 5770
|
GCRaistlin ·
01-Фев-24 23:14
(спустя 26 мин.)
Hanabishi писал(а):
85821083Почитайте о принципах работы HDD
Спасибо, я в курсе их. 25 лет на этом специализируюсь.
Задайтесь вопросом: что обеспечивает кеш чтения?
|
|
|
|
Hanabishi
Стаж: 14 лет 7 месяцев Сообщений: 2897
|
Hanabishi ·
01-Фев-24 23:20
(спустя 5 мин., ред. 01-Фев-24 23:28)
GCRaistlin писал(а):
85821192Спасибо, я в курсе их. 25 лет на этом специализируюсь.
Тогда вроде и вопросов быть не должно. Больше пиров качает разные файлы => больше времени тратится на позиционирование головок => ниже скорость.
Тут есть люди, у которых и 1000 пиров одновременно бывает. На таких сценариях уже даже SSD (нижнего ценового сегмента) начинают упираться в IOPS.
GCRaistlin писал(а):
85821192Задайтесь вопросом: что обеспечивает кеш чтения?
Мы этим как раз и занимаемся.
|
|
|
|
GCRaistlin
Стаж: 16 лет 10 месяцев Сообщений: 5770
|
GCRaistlin ·
01-Фев-24 23:45
(спустя 24 мин.)
Hanabishi писал(а):
85821214Больше пиров качает разные файлы => больше времени тратится на позиционирование головок => ниже скорость.
А если пиры качают один и тот же файл размером в десятки гигабайт, времени на позиционирование головок тратится меньше?
|
|
|
|
stаlkerok
Стаж: 1 год 9 месяцев Сообщений: 1818
|
stаlkerok ·
01-Фев-24 23:48
(спустя 2 мин.)
GCRaistlin, столько же, усугубит ситуацию сильная фрагментация файла.
|
|
|
|
GCRaistlin
Стаж: 16 лет 10 месяцев Сообщений: 5770
|
GCRaistlin ·
01-Фев-24 23:51
(спустя 3 мин.)
stаlkerok
Фрагментация - это, конечно, плохо. Но как тут поможет кеш чтения?
|
|
|
|
Hanabishi
Стаж: 14 лет 7 месяцев Сообщений: 2897
|
Hanabishi ·
02-Фев-24 00:28
(спустя 36 мин., ред. 02-Фев-24 00:28)
GCRaistlin писал(а):
85821313А если пиры качают один и тот же файл размером в десятки гигабайт, времени на позиционирование головок тратится меньше?
Нет. Подразумевалось "разные места на диске". Разные это файлы или части одного большого, при условии случайного доступа, особо значения не имеет.
Опять же, раз на этом специализируетесь, то должны знать, что на уровне диска нет никаких файлов, а есть только сектора (блоки) данных.
GCRaistlin писал(а):
85821346Фрагментация - это, конечно, плохо. Но как тут поможет кеш чтения?
В этом как раз весь вопрос. Как минимум кэш дает вероятность, что если разные пиры захотят один и тот же блок, его не придется читать с диска снова. Собственно в кубите в окошке статистики есть процент попаданий в кэш чтения.
С другой стороны, кэш ОС тоже без дела не сидит и держит в памяти все прочитанное насколько это возможно. Поэтому в принципе я и ставлю полезность клиентского кэша под вопрос.
Плюс еще есть такая интересная опция как "Отправлять предложения частей отдачи". С ней клиент пытается предлагать пирам скачать имеющиеся в кэше части вместо рандомного выбора. И вот это уже без клиентского кэша не реализовать.
И еще libtorrent 1.2 читает данные на упреждение. Хотя он это делает даже если кэш отключен, так как у него буфер чтения и кэш частей это две отдельные вещи. При чем в буфер попадания тоже могут быть.
Отсутствие буфера кстати тоже один из бичей libtorrent 2.0, отчего его производительность заметно хуже даже на SSD, что показано в тестах выше.
stаlkerok, кстати, может у нас еще разные результаты из-за размеров буфера?
У меня стоит
Send buffer watermark: 1024 KiB
Send buffer low watermark: 128 KiB
Send buffer watermark factor: 100%
|
|
|
|
GCRaistlin
Стаж: 16 лет 10 месяцев Сообщений: 5770
|
GCRaistlin ·
02-Фев-24 00:43
(спустя 15 мин., ред. 02-Фев-24 00:43)
Hanabishi писал(а):
85821428Подразумевалось "разные места на диске". Разные это файлы или части одного большого, при условии случайного доступа, особо значения не имеет.
Доступ, с точки зрения диска/ОС, как раз случайный. И "места на диске" будут все время разные.
Hanabishi писал(а):
85821428Как минимум кэш дает вероятность, что если разные пиры захотят один и тот же блок, его не придется читать с диска снова.
Эта вероятность при эффективном алгоритме файлообмена стремится к нулю.
Hanabishi писал(а):
85821428еще есть такая интересная опция как "Отправлять предложения частей отдачи". С ней клиент пытается предлагать пирам скачать имеющиеся в кэше части вместо рандомного выбора.
Не удивлюсь, если пиры посылают клиента с такими предложениями куда подальше.
Hanabishi писал(а):
85821428libtorrent 1.2 читает данные на упреждение.
Допустим, это так (я не знаю). Но это бессмысленно: клиент не знает, какой следующий кусок у него попросят.
stаlkerok писал(а):
85821328усугубит ситуацию сильная фрагментация файла.
По размышлении я пришел к выводу, что не особо. Это при линейном чтении критично.
|
|
|
|
Hanabishi
Стаж: 14 лет 7 месяцев Сообщений: 2897
|
Hanabishi ·
02-Фев-24 01:04
(спустя 20 мин.)
GCRaistlin писал(а):
85821496Доступ, с точки зрения диска/ОС, как раз случайный. И "места на диске" будут все время разные.
Можно и линейно читать. Просто торрент-клиенты как правило так не делают (если не стоит опция "загружать последовательно").
GCRaistlin писал(а):
85821496Эта вероятность при эффективном алгоритме файлообмена стремится к нулю.
Нет, вероятность есть и неплохая. Вкладка статистики в помощь опять же, можно и у народа поспрашивать. Обычно в переделах 20-30% колеблется. Некоторые и 50% показывали. Но тут опять же от количества, размера, популярности раздач зависит итд.
GCRaistlin писал(а):
85821496Не удивлюсь, если пиры посылают клиента с такими предложениями куда подальше.
Сложно проверить. Вроде как в клиентах нет опции типа "отказываться от предлагаемых частей". Но в том же uTorrent-е например код закрыт и что он там делает сказать наверняка нельзя.
GCRaistlin писал(а):
85821496Допустим, это так (я не знаю). Но это бессмысленно: клиент не знает, какой следующий кусок у него попросят.
Это упреждающее чтение в рамках одной части. Если размер части в торренте например 1 МБ, пиры не могут попросить только кусок от нее, часть всегда будет выкачана целиком.
GCRaistlin писал(а):
85821496По размышлении я пришел к выводу, что не особо. Это при линейном чтении критично.
Чтение в торренте не супер рандомно. Части в торрентах как правило измеряются мегабайтами и в рамках такой части чтение идет линейно. А фрагментация может файлы размазать хоть по 1 кластеру (то есть по 4 КБ в общем случае).
Плюс чем ближе части располагаются на диске, тем быстрее позиционирование. Это тоже влияет и потому дефрагментация нужна.
|
|
|
|
GCRaistlin
Стаж: 16 лет 10 месяцев Сообщений: 5770
|
GCRaistlin ·
02-Фев-24 01:44
(спустя 40 мин.)
Hanabishi писал(а):
85821569Нет, вероятность есть и неплохая. Вкладка статистики в помощь опять же
И это еще я qB использую только для вытягивания сложных раздач - что иногда как раз предполагает многократную отдачу одного и того же (нет полного сида => куча народу хочет одних и тех же кусков).
Покажите, пож., вашу.
Hanabishi писал(а):
85821569если не стоит опция "загружать последовательно"
Это где?
Hanabishi писал(а):
85821569Вроде как в клиентах нет опции типа "отказываться от предлагаемых частей".
Предположу (опять-таки не знаю), что BitTorrent реализован наоборот: клиент сообщает, что есть в наличии, и отдает то, что попросили. Может, опционально фича "возьмите лучше это" и реализована, но право выбора куска должно оставаться за личером.
Hanabishi писал(а):
85821569Это упреждающее чтение в рамках одной части.
Какое же это упреждающее чтение? Это просто чтение.
Hanabishi писал(а):
85821569Чтение в торренте не супер рандомно.
Чтение кусков - рандомно.
Hanabishi писал(а):
85821569фрагментация может файлы размазать хоть по 1 кластеру (то есть по 4 КБ в общем случае).
Теоретически да, но это сферический конь в вакууме.
Ближайший реальный сценарий - использование NTFS-сжатия. Я одно время этим баловался: на 2 TB позволяет выиграть 10-20 GB. Но взамен получаем тормоза даже при просмотре фильмов. Как только я осознал их причину, баловаться перестал.
Hanabishi писал(а):
85821569Плюс чем ближе части располагаются на диске, тем быстрее позиционирование. Это тоже влияет
Только в отдельных сценариях, например при раздаче BDRemux.
Если раздача состоит из нескольких файлов, то никакой дефрагментацией вы их лечь рядышком не заставите, а значит, головки могут гоняться туда-сюда, даже если она состоит из совершенно нефрагментированных файлов.
|
|
|
|
Hanabishi
Стаж: 14 лет 7 месяцев Сообщений: 2897
|
Hanabishi ·
02-Фев-24 02:41
(спустя 56 мин., ред. 02-Фев-24 11:47)
GCRaistlin писал(а):
85821655Покажите, пож., вашу.
Не могу, у меня клиент с libtorrent 2.0. А даже когда пользовался 1.2, кэш в клиенте отключал.
GCRaistlin писал(а):
85821655Это где?
При добавлении торрента галка. Или ПКМ по существующему торренту, там она тоже есть.
GCRaistlin писал(а):
85821655Какое же это упреждающее чтение? Это просто чтение.
Это уже бесполезный спор о терминах. Там размер буфера расчитывается из текущей скорости пира и данные читаются на некоторое время вперед. Как это называть не суть важно.
GCRaistlin писал(а):
85821655Чтение кусков - рандомно.
Только куски эти здоровые в несколько мегабайт, что уже вполне можно относить в разряд линейного чтения. Тру рандом это чтение по 4 КБ.
Хаос начинается когда нужно несколько частей параллельно читать, вот тогда да, начинаются скачки головки туда-сюда.
GCRaistlin писал(а):
85821655Теоретически да, но это сферический конь в вакууме.
Так мы про общую теорию и разговариваем. Надо или не надо проводить дефрагментацию можно смотреть по факту.
Собственно в винде например автоматическая дефрагментация на определенном пороге фрагментации запускается.
GCRaistlin писал(а):
85821655Только в отдельных сценариях, например при раздаче BDRemux.
Опять же мы общий случай обсуждаем. Если такие сценарии есть, то значит их нужно учитывать.
GCRaistlin писал(а):
85821655Если раздача состоит из нескольких файлов, то никакой дефрагментацией вы их лечь рядышком не заставите
Кстати есть утилиты, которые позволяют это сделать.
|
|
|
|
GCRaistlin
Стаж: 16 лет 10 месяцев Сообщений: 5770
|
GCRaistlin ·
02-Фев-24 03:44
(спустя 1 час 3 мин., ред. 02-Фев-24 03:44)
Hanabishi писал(а):
85821768Или ПКМ по существующему торренту, там она тоже есть.
Не вижу.
Hanabishi писал(а):
85821768Это уже бесполезный спор о терминах. Там размер буфера расчитывается из текущей скорости пира и данные читаются на некоторое время вперед. Как это называть не суть важно.
Клиент не способен ни принять, ни отдать данные размером меньше куска. У него его попросили - он его считывает. Что тут упреждающего?
Hanabishi писал(а):
85821768Только куски эти здоровые в несколько мегабайт, что уже вполне можно относить в разряд линейного чтения.
Линейное чтение характеризуется условным отсутствием затрат времени на позиционирование голов. Когда вы после чтения каждых нескольких МБ перепозиционируете головы, это уже никакое не линейное чтение: затраты времени на позиционирование будут относительно велики.
Hanabishi писал(а):
85821768Так мы про общую теорию и разговариваем. Надо или не надо проводить дефрагментацию можно смотреть по факту.
Можно априори утверждать, что если не используется NTFS-сжатие, то фрагментация никогда не достигнет чувствительных для раздач торрентов значений.
Hanabishi писал(а):
85821768Кстати есть утилиты, которые позволяют это сделать.
Например?
Hanabishi писал(а):
85821768Если такие сценарии есть, то значит их нужно учитывать.
Есть в том смысле, что разница в этом сценарии при раздаче фрагментированного/нефрагментированного файла есть хотя бы формальная и рационально обоснованная. По факту, естественно, гораздо важнее (затратнее по времени) сам факт движения голов, чем расстояние, на которое они движутся. А при других сценариях и этого нет.
|
|
|
|
esoshurkov
Стаж: 1 год 9 месяцев Сообщений: 55
|
esoshurkov ·
02-Фев-24 07:39
(спустя 3 часа, ред. 02-Фев-24 07:39)
Hanabishi писал(а):
85821428С другой стороны, кэш ОС тоже без дела не сидит и держит в памяти все прочитанное насколько это возможно. Поэтому в принципе я и ставлю полезность клиентского кэша под вопрос.
я думаю в разрезе линуксов-докеров, и вот что выходит: hdd(кэш 512мб) -> ОС Линукс (просто юзает всю память что не занята под Кэш Диска) -> Докер (тот же ОС Линукс, так же юзает свою всю память под кэш Диска что выделила ему ОС-мать) -> Кэш в Кубите.
Не много ли кэшей по пути к диску? ) Стойкое ощущение, что где-то идет задвоение, затроение, а может даже зачетверение информации! )
не знаю, как в Винде. Но наблюдая за тем, как ОС и Докер заполняют остатки памяти кэшем под "что-то свое", ну наверняка это дисковый ввод-вывод, т.к. больше в эксперименте-наблюдении у меня нету процессов, кроме кубита - невольно думаешь, дак может имеет смысл и отключить кэш в Кубите.
|
|
|
|
Hanabishi
Стаж: 14 лет 7 месяцев Сообщений: 2897
|
Hanabishi ·
02-Фев-24 11:34
(спустя 3 часа, ред. 02-Фев-24 11:51)
GCRaistlin писал(а):
85821835Не вижу.
Может версия клиента древняя? В текущей так
GCRaistlin писал(а):
85821835Клиент не способен ни принять, ни отдать данные размером меньше куска. У него его попросили - он его считывает. Что тут упреждающего?
Да, это называется буферизованное чтение, а не упреждающее. По ночам голова не всегда варит.
GCRaistlin писал(а):
85821835Линейное чтение характеризуется условным отсутствием затрат времени на позиционирование голов. Когда вы после чтения каждых нескольких МБ перепозиционируете головы, это уже никакое не линейное чтение: затраты времени на позиционирование будут относительно велики.
Вот именно. Но кто определяет границу? Затраты "относительно велики" довольно размытая величина. Какой объем тогда можно считать за линейное? 100 МБ - линейное? 1 ГБ - линейное?
Или может линейное это только когда читаешь диск целиком от начала до конца без единого перепозиционирования? 
GCRaistlin писал(а):
85821835Можно априори утверждать, что если не используется NTFS-сжатие, то фрагментация никогда не достигнет чувствительных для раздач торрентов значений.
NTFS не единственная фс в природе. Да и заниматься предсказыванием таких вещей я бы не стал, здесь лучше всегда предполагать наихудший сценарий, по моему мнению.
GCRaistlin писал(а):
85821835Например?
Дерагментатор от Auslogics вроде такое когда-то мог, емнип. Какие-то другие может тоже. Во времена хардов такие функции были популярны, например важные и системные файлы сдвигались в начало диска, так как там быстрая зона.
Сейчас уже не помню точно, давно не пользуюсь ни хардами (как активным хранилищем), ни виндой.
GCRaistlin писал(а):
85821835По факту, естественно, гораздо важнее (затратнее по времени) сам факт движения голов, чем расстояние, на которое они движутся.
Это да, не спорю. Упомянуто было как дополнительный фактор.
esoshurkov писал(а):
85822151ОС Линукс (просто юзает всю память что не занята под Кэш Диска) -> Докер (тот же ОС Линукс, так же юзает свою всю память под кэш Диска что выделила ему ОС-мать)
Такого не должно быть вроде как. Докер это не виртуалка, он крутится на том же ядре. У них VFS кэш один общий по идее должен быть, без дублирования.
Но прямо сейчас не возьмусь утверждать.
esoshurkov писал(а):
85822151где-то идет задвоение
esoshurkov писал(а):
85822151невольно думаешь, дак может имеет смысл и отключить кэш в Кубите.
Кэш ОС + кэш клиента это точно задвоение. Опять же почему я его считаю не особо полезным. Результаты моих тестов есть выше.
Но у stаlkerok вон результаты без кэша плохие, так что лучше проводить собственные тесты.
esoshurkov писал(а):
85822151не знаю, как в Винде
Так же. ОС кэшит файлы по максимуму, насколько есть свободной памяти.
|
|
|
|
esoshurkov
Стаж: 1 год 9 месяцев Сообщений: 55
|
esoshurkov ·
02-Фев-24 12:29
(спустя 55 мин.)
Цитата:
Кэш ОС + кэш клиента это точно задвоение. Опять же почему я его считаю не особо полезным. Результаты моих тестов есть выше.
в докере выглядит как, убрал кэш кубиту, он жрет 43 Мб ОЗУ, а в докере лимит 1 Гб сделал. И вот при запуске докер показывает что постепенно память сжирается системой докера до 1Гб, а кубит в процессах все еще на 43Мб. В этом докере естественно сидит кубит как самый жирный гусь.
Ну я так и оставил, и еще сделал only TCP, на роутере тоже оставил проброс только TCP.
Т.к. все это на SSD, в целом мне главное чтобы ЦПУ не жрало и память особо.
В итоге с такой конфой пока оставлю кубит работать, раздача легко все 500Мб канал забивает. Больше мне и не надо. Теперь главное, чтобы было стабильно. А, ну и да - по температуре ССД на 38 градусах, это косвенное мое наблюдение, как часто оно без кэша туда ходит. Если б ССД стал нагреваться побольше, значит нагрузка на него пошла больше. А так-то все тихо и спокойно, что с кэшем, что без (я про кубитный если что).
Продолжаем наблюдать, но похоже это последние мои потуги с настройкой кубита и переезда с трансмиссии ) надеюсь.
|
|
|
|
Hanabishi
Стаж: 14 лет 7 месяцев Сообщений: 2897
|
Hanabishi ·
02-Фев-24 12:36
(спустя 6 мин., ред. 02-Фев-24 12:38)
esoshurkov писал(а):
85823011докер показывает что постепенно память сжирается системой докера до 1Гб
А родительская ось что показывает? Эта память считается как использованная (колонка used в команде free -wh)?
Если не идет в использованную, то может лучше вообще ограничение снять. Пусть кэшит на всю доступную оперативу.
|
|
|
|
raddyst
Стаж: 10 лет 10 месяцев Сообщений: 416
|
raddyst ·
02-Фев-24 13:24
(спустя 48 мин., ред. 02-Фев-24 13:24)
GCRaistlin писал(а):
85821835Например?
wincontig (при явном указании зоны диска, где должен находиться каталог)
|
|
|
|
