|
|
|
Senatorov
Стаж: 15 лет 8 месяцев Сообщений: 68
|
Senatorov ·
06-Сен-25 21:35
(20 дней назад)
stаlkerok столько лет клиенту, думал, уже все проверено по нескольку раз)
я пробовал ставить разные настройки, но у меня не тот трафик и не то количество раздач, что бы можно было делать однозначные выводы.
Больше всего интересует это
скрытый текст
- Кэш диска = -1 для windows тут без вариантов? и как избежать утечку ram? гпт советует отключить кэш ос на чтение и в этом параметре поставить 1024 или 2048
- Период очистки кэша диска = 60?
- Отметка буфера отправки, Нижняя отметка буфера отправки, Фактор отметки буфера отправки = может есть оптимальный рабочий баланс этих параметров?
- Тип обслуживания (ToS) соединений к пирам = на сколько это работает, например если поменять на 104?
|
|
|
|
x86-64
Стаж: 7 лет 3 месяца Сообщений: 28849
|
x86-64 ·
06-Сен-25 21:37
(спустя 2 мин., ред. 06-Сен-25 21:37)
Senatorov
Я добавил несколько пунктов в инструкцию
Senatorov писал(а):
88179702и как избежать утечку ram?
А где вы ее увидели? Или просто слышали модную фразу? Это как "оптимизация" в играх, все говорят, но никто не знает, что это
|
|
|
|
stаlkerok
Стаж: 2 года 7 месяцев Сообщений: 2935
|
stаlkerok ·
06-Сен-25 21:49
(спустя 12 мин.)
Senatorov писал(а):
88179702столько лет клиенту, думал, уже все проверено по нескольку раз)
Тут всё индивидуально. Например, я такие запредельные значения никогда юзать не стал бы.
x86-64 писал(а):
54845953Период очистки кэша диска — 2147483647 с
Размер очереди диска — 2097151 КБ
При таких значениях эти настройки не отрабатывают и теряют смысл.
|
|
|
|
x86-64
Стаж: 7 лет 3 месяца Сообщений: 28849
|
x86-64 ·
06-Сен-25 21:51
(спустя 1 мин.)
stаlkerok писал(а):
88179766эти настройки не отрабатывают
Потому что - ?
Эти настройки взяты у https://rutr.life/forum/profile.php?mode=viewprofile&u=13843868
|
|
|
|
stаlkerok
Стаж: 2 года 7 месяцев Сообщений: 2935
|
stаlkerok ·
06-Сен-25 22:14
(спустя 22 мин., ред. 06-Сен-25 22:14)
x86-64, мы ведь уже говорили об этом.
x86-64 писал(а):
54845953Период очистки кэша диска — 2147483647 с
Кэш фактически не используется, так как не очищается. Не работает, как надо.
x86-64 писал(а):
54845953Размер очереди диска — 2097151 КБ
Если кэш не используется, значит данные пишутся сразу на диск, ну или просто высвобождается какая-то малая его часть. 8 - 16 МБ с кэшем 4 ГБ у меня хватает что бы качать на весь гигабит на HDD. Если не хватает, значит с диском что-то не так, и нужно смотреть диск, а не тупо увеличивать очередь. Ну или я хз насколько допотопный или убитый должен быть HDD.
Ну и кстати, а потом люди будут спрашивать такое 
Senatorov писал(а):
88179702и как избежать утечку ram?
|
|
|
|
Senatorov
Стаж: 15 лет 8 месяцев Сообщений: 68
|
Senatorov ·
06-Сен-25 22:22
(спустя 8 мин.)
x86-64 писал(а):
Я добавил несколько пунктов в инструкцию
благодарю.
а почему, можете объяснить?
скрытый текст
Отметка буфера отправки — 4096 КБ
Нижняя отметка буфера отправки — 128 КБ
Фактор отметки буфера отправки — 100%
Источник
скрытый текст
send_buffer_low_watermark the minimum send buffer target size (send buffer includes bytes pending being read from disk). For good and snappy seeding performance, set this fairly high, to at least fit a few blocks. This is essentially the initial window size which will determine how fast we can ramp up the send rate
if the send buffer has fewer bytes than send_buffer_watermark, we'll read another 16 kiB block onto it. If set too small, upload rate capacity will suffer. If set too high, memory will be wasted. The actual watermark may be lower than this in case the upload rate is low, this is the upper limit.
the current upload rate to a peer is multiplied by this factor to get the send buffer watermark. The factor is specified as a percentage. i.e. 50 -> 0.5 This product is clamped to the send_buffer_watermark setting to not exceed the max. For high speed upload, this should be set to a greater value than 100. For high capacity connections, setting this higher can improve upload performance and disk throughput. Setting it too high may waste RAM and create a bias towards read jobs over write jobs.
рекомендация гпт
скрытый текст
1. чуть проще
send_buffer_watermark = 2048 КБ
send_buffer_low_watermark = 256 КБ
send_buffer_watermark_factor = 150%
2. чуть агрессивнее
send_buffer_watermark = 4096 КБ
send_buffer_low_watermark = 512 КБ
send_buffer_watermark_factor = 200%
Для высокой скорости раздачи (особенно при высоком аплоаде) рекомендуется значение больше 100.
Для высокопроизводительных соединений увеличение этого значения может улучшить скорость отдачи и производительность диска.
x86-64 писал(а):
А где вы ее увидели?
при раздаче забивается ram и не скидывается дост. долгое время. помогает только закрытие клиента
и еще
скрытый текст
Период очистки кэша диска — 2147483647с
Размер очереди диска — 2097151 КБ
зачем так долго держать данные в кэше, когда базовый параметр 60сек
2097151кб = 2 048мб это столько данных будет висеть вначале в ram, а потом разово залетит на диск. вы ничего не путаете?
|
|
|
|
stаlkerok
Стаж: 2 года 7 месяцев Сообщений: 2935
|
stаlkerok ·
06-Сен-25 22:29
(спустя 7 мин., ред. 06-Сен-25 22:37)
Я не экспериментировал с такими значениями, но, по моему, с таким периодом очистки кэша диска, очередь всегда будет большой.
Да, кстати, всё время забываю, что FAQ можно написать с помощью ИИ 
Senatorov, хотите уменьшить потребление рам, уменьшайте значения кэша диска и пула файлов.
|
|
|
|
Romski
Стаж: 15 лет 2 месяца Сообщений: 3662
|
Romski ·
06-Сен-25 22:31
(спустя 1 мин.)
Вот бы какой-нить калькулятор сделали, куда вводишь своё железо + скорость интернета и на основании этого примерные настройки с которых можно было бы начать 
|
|
|
|
stаlkerok
Стаж: 2 года 7 месяцев Сообщений: 2935
|
stаlkerok ·
06-Сен-25 22:32
(спустя 1 мин.)
Romski, можно с ИИ играться, чем не калькулятор?)
|
|
|
|
Romski
Стаж: 15 лет 2 месяца Сообщений: 3662
|
Romski ·
06-Сен-25 22:37
(спустя 4 мин.)
stаlkerok
После предыдущих сообщений я тоже об этом задумался, всё никак не привыкну к этим новым технологиям и что их можно обо всём спрашивать)
|
|
|
|
Senatorov
Стаж: 15 лет 8 месяцев Сообщений: 68
|
Senatorov ·
06-Сен-25 23:04
(спустя 26 мин.)
stаlkerok писал(а):
Да, кстати, всё время забываю, что FAQ можно написать с помощью ИИ
хоть я что то дельное подсказал, уже радует)
stаlkerok так я и обратился за советом к мудрым, и опытным, и пытаюсь разобраться.
проблема есть - это факт. решение проблемы не могу понять, у меня сейчас и так стоит -1
как вариант ии предлагает - увеличить "Кэш диска" до 1024 или до 2048 и "Режим чтения ввода-вывода с диска" = отключить кэш ос. Это рабочий вариант или нет?
|
|
|
|
stаlkerok
Стаж: 2 года 7 месяцев Сообщений: 2935
|
stаlkerok ·
06-Сен-25 23:12
(спустя 8 мин.)
Senatorov писал(а):
88180007решение проблемы не могу понять, у меня сейчас и так стоит -1
Это автоматический выбор размера кэша на основе объёма RAM.
Senatorov писал(а):
88180007увеличить "Кэш диска" до 1024 или до 2048
Я не знаю сколько у вас в авторежиме. Если вам нужно уменьшить, попробуйте кэш 64мб, пул файлов 20, и понаблюдайте.
Senatorov писал(а):
88180007"Режим чтения ввода-вывода с диска" = отключить кэш ос.
Этого делать не рекомендую.
|
|
|
|
Senatorov
Стаж: 15 лет 8 месяцев Сообщений: 68
|
Senatorov ·
07-Сен-25 00:20
(спустя 1 час 8 мин.)
|
|
|
|
incognito_assassin
Стаж: 14 лет 7 месяцев Сообщений: 72
|
incognito_assassin ·
07-Сен-25 01:51
(спустя 1 час 30 мин., ред. 07-Сен-25 01:51)
Здравствуйте. Прочитал последнии сообщения в теме, не нашёл ответ. Перестал учитывать статистику отданного в профиле. Можно как-то починить? qB 5.1.2
|
|
|
|
CeyT
Стаж: 17 лет 5 месяцев Сообщений: 89
|
CeyT ·
07-Сен-25 05:02
(спустя 3 часа)
Клиент пишет ошибки соединения с трекером? Связи нет постоянно, или случайным образом статистика обновляется?
Если дело в полной недоступности, пользуйтесь методами обхода блокировок. Если дело в том, что сервер перегружен или не принимает запросы, то на не работающий сервер вы их и так не отправите. Можно попытаться и в этом случае пойти в обход, в надежде на то, что ваш диапазон адресов временно заблокирован из-за атаки, а с другого пройдёт, например.
Статистика нужна для красоты, если вы не пользуетесь списками на сайте для ручного управления, что ещё надо загрузить или раздать.
|
|
|
|
Hanabishi
Стаж: 15 лет 5 месяцев Сообщений: 3053
|
Hanabishi ·
07-Сен-25 13:48
(спустя 8 часов)
incognito_assassin писал(а):
88180359Перестал учитывать статистику отданного в профиле.
Клиент ни при чем, читайте общие темы трекера.
|
|
|
|
x86-64
Стаж: 7 лет 3 месяца Сообщений: 28849
|
x86-64 ·
07-Сен-25 13:57
(спустя 9 мин.)
stаlkerok писал(а):
88179837Кэш фактически не используется, так как не очищается.
С чего вдруг-то он не используется? Такое может быть только если он не обновляется, что, в таком случае, является багом.
Senatorov писал(а):
88179890при раздаче забивается ram и не скидывается дост. долгое время.
А должен скидываться? Забивается неиспользуемая память для того, чтобы лишний раз не дергать файлы на накопителе
|
|
|
|
Mixin
Стаж: 18 лет 8 месяцев Сообщений: 879
|
Mixin ·
07-Сен-25 19:07
(спустя 5 часов)
Senatorov писал(а):
зачем так долго держать данные в кэше, когда базовый параметр 60сек
2097151кб = 2 048мб это столько данных будет висеть вначале в ram, а потом разово залетит на диск. вы ничего не путаете?
Забьёт всё что дадите, как раздавать начнет. И будет держать до завершения работы даже, если раздача по нулям будет.
|
|
|
|
Senatorov
Стаж: 15 лет 8 месяцев Сообщений: 68
|
Senatorov ·
07-Сен-25 21:47
(спустя 2 часа 39 мин., ред. 07-Сен-25 21:47)
x86-64 очень хотело бы услышать аргументы по вашим рекомендациям по настройке, а именно:
скрытый текст
Отметка буфера отправки — 4096 КБ
Нижняя отметка буфера отправки — 128 КБ
Фактор отметки буфера отправки — 100%
Период очистки кэша диска — 2147483647с
Размер очереди диска — 2097151 КБ
Это как то проверялось? Сколько было раздач? Какая скорость?
Лично по моему опыту, данные настройки скорее снижают производительность и стабильность отдачи
заранее, спасибо!
Mixin писал(а):
88182683
Senatorov писал(а):
зачем так долго держать данные в кэше, когда базовый параметр 60сек
2097151кб = 2 048мб это столько данных будет висеть вначале в ram, а потом разово залетит на диск. вы ничего не путаете?
Забьёт всё что дадите, как раздавать начнет. И будет держать до завершения работы даже, если раздача по нулям будет.
Не очень понятно, зачем, если речь про раздачу
|
|
|
|
Mixin
Стаж: 18 лет 8 месяцев Сообщений: 879
|
Mixin ·
07-Сен-25 22:08
(спустя 20 мин., ред. 07-Сен-25 22:08)
Senatorov
Я не знаю, почему так. Описываю исключительно то, что у себя вижу. Настройки я никакие не менял, кроме размера этого самого кэша и отсутствия лимита
подключений. Возможно, если следовать рекомендациям тов. stаlkerok, может и иначе будет.
|
|
|
|
Senatorov
Стаж: 15 лет 8 месяцев Сообщений: 68
|
Senatorov ·
07-Сен-25 22:31
(спустя 23 мин., ред. 07-Сен-25 22:31)
Mixin
речь тут про рекомендации ув. x86-64 которые недавно появились на первой странице. а ув. stаlkerok отвечал и спасибо ему за это, про утечку озу
скрытый текст
Senatorov писал(а):
88179890
x86-64 писал(а):
Я добавил несколько пунктов в инструкцию
благодарю.
а почему, можете объяснить?
скрытый текст
Отметка буфера отправки — 4096 КБ
Нижняя отметка буфера отправки — 128 КБ
Фактор отметки буфера отправки — 100%
Источник
скрытый текст
send_buffer_low_watermark the minimum send buffer target size (send buffer includes bytes pending being read from disk). For good and snappy seeding performance, set this fairly high, to at least fit a few blocks. This is essentially the initial window size which will determine how fast we can ramp up the send rate
if the send buffer has fewer bytes than send_buffer_watermark, we'll read another 16 kiB block onto it. If set too small, upload rate capacity will suffer. If set too high, memory will be wasted. The actual watermark may be lower than this in case the upload rate is low, this is the upper limit.
the current upload rate to a peer is multiplied by this factor to get the send buffer watermark. The factor is specified as a percentage. i.e. 50 -> 0.5 This product is clamped to the send_buffer_watermark setting to not exceed the max. For high speed upload, this should be set to a greater value than 100. For high capacity connections, setting this higher can improve upload performance and disk throughput. Setting it too high may waste RAM and create a bias towards read jobs over write jobs.
рекомендация гпт
скрытый текст
1. чуть проще
send_buffer_watermark = 2048 КБ
send_buffer_low_watermark = 256 КБ
send_buffer_watermark_factor = 150%
2. чуть агрессивнее
send_buffer_watermark = 4096 КБ
send_buffer_low_watermark = 512 КБ
send_buffer_watermark_factor = 200%
Для высокой скорости раздачи (особенно при высоком аплоаде) рекомендуется значение больше 100.
Для высокопроизводительных соединений увеличение этого значения может улучшить скорость отдачи и производительность диска.
x86-64 писал(а):
А где вы ее увидели?
при раздаче забивается ram и не скидывается дост. долгое время. помогает только закрытие клиента
и еще
скрытый текст
Период очистки кэша диска — 2147483647с
Размер очереди диска — 2097151 КБ
зачем так долго держать данные в кэше, когда базовый параметр 60сек
2097151кб = 2 048мб это столько данных будет висеть вначале в ram, а потом разово залетит на диск. вы ничего не путаете?
|
|
|
|
x86-64
Стаж: 7 лет 3 месяца Сообщений: 28849
|
x86-64 ·
08-Сен-25 11:29
(спустя 12 часов)
Senatorov писал(а):
88183063очень хотело бы услышать аргументы по вашим рекомендациям по настройке
Про буфер их писал, насколько я помню, Hanabishi в этой теме. Остальное указано для снижения лишних обращений к диску
|
|
|
|
Hanabishi
Стаж: 15 лет 5 месяцев Сообщений: 3053
|
Hanabishi ·
08-Сен-25 12:42
(спустя 1 час 13 мин., ред. 08-Сен-25 16:20)
Senatorov писал(а):
88183462а почему, можете объяснить?
Пояснение по параметрам
Отвечая на вопрос почему: значения теоретические для HDD. Суть их в том, что жесткие диски тратят много времени на позиционирование, и чем линейнее доступ, тем выше производительность.
Сам либторрент (по крайней мере 2 версии) читает данные блоками по 16 КБ. Для хардов это критически низкое значение, где оверхед от позиционирования значительно превышает время непосредственного чтения-записи данных. Чисто эмпирическим путем выяснено, что для HDD чтение меньше чем примерно 128 КБ за раз не имеет смысла, затраченное на операцию время не уменьшается. То же самое с верхним пределом, где-то от 4 МБ видимого прироста от линейности больше не наблюдается. Но значения разумеется могут варьироваться в зависимости от конкретной модели диска.
Почему значения называю теоретическими, не учитываются некоторые моменты:
1. Фрагментация данных на уровне файловой системы. Чтение определенного количества данных из файла не означает, что физически они будут лежать последовательно. Тут ничего не поделать, только проводить дефрагментацию.
2. Современные ОС имеют механизм read-ahead и читают наперед в любом случае, если вызывающая программа явно не отключает это поведение. Какие параметры имеет винда не скажу, но в линуксах упреждающее чтение как правило составляет 128 КБ.
3. В memory-mapped режиме либторрента 2.x вообще непонятно сколько данных будет реально прочитано. Тут можно целое отдельное исследование проводить.
|
|
|
|
Senatorov
Стаж: 15 лет 8 месяцев Сообщений: 68
|
Senatorov ·
08-Сен-25 15:24
(спустя 2 часа 42 мин., ред. 08-Сен-25 16:12)
x86-64
Hanabishi
Благодарю за ответы.
Источник
скрытый текст
send_buffer_low_watermark the minimum send buffer target size (send buffer includes bytes pending being read from disk). For good and snappy seeding performance, set this fairly high, to at least fit a few blocks. This is essentially the initial window size which will determine how fast we can ramp up the send rate
if the send buffer has fewer bytes than send_buffer_watermark, we'll read another 16 kiB block onto it. If set too small, upload rate capacity will suffer. If set too high, memory will be wasted. The actual watermark may be lower than this in case the upload rate is low, this is the upper limit.
the current upload rate to a peer is multiplied by this factor to get the send buffer watermark. The factor is specified as a percentage. i.e. 50 -> 0.5 This product is clamped to the send_buffer_watermark setting to not exceed the max. For high speed upload, this should be set to a greater value than 100. For high capacity connections, setting this higher can improve upload performance and disk throughput. Setting it too high may waste RAM and create a bias towards read jobs over write jobs.
Разбор ИИ
скрытый текст
send_buffer_low_watermark
Перевод: Минимальный целевой размер буфера отправки.
Пояснение: Буфер отправки — это область памяти, куда загружаются данные с диска, прежде чем быть отправленными другим пирами.
Этот параметр задаёт минимальный объём данных, который должен находиться в буфере.
Если значение маленькое — отдача может быть "рваной", скорость будет низкой.
Если значение высокое — клиент сможет быстрее "раскачать" скорость отдачи.
Рекомендация: ставить достаточно большим, чтобы туда помещалось несколько блоков данных (один блок = 16 КиБ).
send_buffer_watermark
Перевод: Верхняя граница размера буфера отправки.
Пояснение: Если в буфере данных меньше, чем это значение — клиент загружает с диска ещё один блок (16 КиБ).
Если значение слишком маленькое — отдача будет тормозить, диск не успевает подгрузить данные.
Если слишком большое — тратится лишняя оперативная память.
Этот параметр — максимальный лимит, реальный размер буфера может быть меньше, если скорость отдачи низкая.
Множитель буфера (send_buffer_watermark_factor)
Перевод: Множитель, по которому рассчитывается текущая цель размера буфера в зависимости от скорости отдачи.
Пояснение: Этот параметр задаётся в процентах. Например:
Значение 50 означает 0.5 — буфер будет рассчитываться как 50% от текущей скорости отдачи.
Если у вас высокая скорость отдачи и вы хотите, чтобы буфер был всегда наполнен — ставьте больше 100.
Пример: Если вы отдаёте 1 МБ/с и множитель — 150, то буфер будет стараться держать 1.5 МБ данных заранее загруженными.
Итоговая рекомендация:
send_buffer_low_watermark — ставьте достаточно высоким (например, 64K или 128K), чтобы обеспечить плавную отдачу.
send_buffer_watermark — не слишком маленький и не слишком большой (например, 512K–2M).
send_buffer_watermark_factor — если у вас высокая скорость интернета и мощный диск, можно ставить от 150 до 300 для лучшей отдачи.
Еще вариант от ИИ с объяснением
Оптимальные настройки send-буферов для 32 ГБ ОЗУ и HDD:
скрытый текст
send_buffer_low_watermark = 256k
send_buffer_watermark = 4096k
send_buffer_watermark_factor = 250
Объяснение параметров:
send_buffer_low_watermark - 256k Немного больше начальный размер буфера, чем обычно, позволяет быстрее начинать передачу и заранее читать с диска.
send_buffer_watermark - 4096k Большой верхний предел буфера, чтобы отдача шла "пачками", снижая нагрузку на HDD. Ты можешь держать много данных в памяти, не беспокоясь за расход ОЗУ.
send_buffer_watermark_factor - 250% Чем выше фактор, тем больше клиент будет буферизировать данных заранее, обеспечивая стабильную отдачу даже при скачках в скорости.
Дополнительно:
Если ты хочешь ещё агрессивнее использовать RAM для снижения нагрузки на HDD и подготовить клиента к пикам отдачи, можешь использовать:
send_buffer_low_watermark = 512k
send_buffer_watermark = 8192k
send_buffer_watermark_factor = 300
Это подойдёт, если у тебя много сидов, высокий аплоад, и HDD справляется без троттлинга.
Я просто пробовал разные варианты (у меня смешанный режим - ssd+hdd+hdd по smb) и при
Отметка буфера отправки — 4096 КБ
Нижняя отметка буфера отправки — 128 КБ
Фактор отметки буфера отправки — 100%
я видел скорее падение в стабильности и в скорости, речь про 5-10 одновременных раздач, на скорости 5-30 мб/сек
более стабильный вариант отдачи нескольких раздач с общей скоростью 5-15мб/сек показывали значения
Отметка буфера отправки — 4096 КБ
Нижняя отметка буфера отправки — 512 КБ
Фактор отметки буфера отправки — 200%
А при скоростях 10 - 20 + мб/сек, так же несколько раздач, еще более стабильные показатели были
Отметка буфера отправки — 8096-16384 КБ
Нижняя отметка буфера отправки — 512 КБ
Фактор отметки буфера отправки — 200%
Вот и пытаюсь разобраться, мне показалось и просто была разная связь и с кэшем тут нет взаимосвязи или такое имеет место быть, все же
|
|
|
|
Ood07
Стаж: 17 лет 5 месяцев Сообщений: 221
|
Ood07 ·
08-Сен-25 16:29
(спустя 1 час 5 мин., ред. 08-Сен-25 16:29)
Senatorov писал(а):
88185100отдачи нескольким сидам
|
|
|
|
Senatorov
Стаж: 15 лет 8 месяцев Сообщений: 68
|
Senatorov ·
08-Сен-25 16:41
(спустя 11 мин., ред. 08-Сен-25 16:41)
Ood07 писал(а):
88185480
Senatorov писал(а):
88185100отдачи нескольким сидам
поправил, спасибо что обратили внимание на важную опечатку)
|
|
|
|
Ood07
Стаж: 17 лет 5 месяцев Сообщений: 221
|
Ood07 ·
08-Сен-25 17:18
(спустя 37 мин., ред. 08-Сен-25 17:18)
Senatorov писал(а):
88185100Разбор ИИ
Senatorov писал(а):
88185100Фактор отметки буфера отправки — 200%
Поставил себе. Вроде и правд ровнее стало.
|
|
|
|
Senatorov
Стаж: 15 лет 8 месяцев Сообщений: 68
|
Senatorov ·
08-Сен-25 18:12
(спустя 53 мин.)
Ood07
глобально, об этом и была речь, рекомендации обусловлены тестами или нет
при раздачах со скоростью 10+, если озу немного, при данных настройках у меня получалось еще стабильнее
Отметка буфера отправки — 4096 КБ
Нижняя отметка буфера отправки — 512 КБ
Фактор отметки буфера отправки — 200-250%
а на второй машине, где озу 32гб, сделал
Отметка буфера отправки — 16384 КБ
Нижняя отметка буфера отправки — 512 КБ
Фактор отметки буфера отправки — 300%
|
|
|
|
Ood07
Стаж: 17 лет 5 месяцев Сообщений: 221
|
Ood07 ·
08-Сен-25 18:27
(спустя 15 мин.)
Senatorov писал(а):
88185954Отметка буфера отправки — 4096 КБ
Нижняя отметка буфера отправки — 512 КБ
у меня 8192 и 256 по типичномк размеру частей торрента
Senatorov писал(а):
88185954если озу немного
Раздаете сотни тысяч одновременно?
|
|
|
|
Senatorov
Стаж: 15 лет 8 месяцев Сообщений: 68
|
Senatorov ·
09-Сен-25 02:13
(спустя 7 часов, ред. 09-Сен-25 02:13)
Ood07
бывает, раздаю понемногу)
и тут же дело не в количестве, а в стабильности скорее. больше буфер, меньше износ диска, стабильнее отдача и скорость, без рывков
x86-64
и в продолжение утечки озу. на машине крутиться qbit + plex, больше ничего не работает. в qbit ограничение озу 1гб. качается 5 торрентов, раздается 5 торрентов. если это не утечка озу, то что тогда? я останавливаю торренты, озу возвращается к 10%
|
|
|
|
