Первые значения — сколько байт будет выделено под буферы при любых условиях.
Второе — при обычном течении «жизни».
Третье — сколько максимум может занять буфер.
Дополнительно можете почитать про tcp_mem, станет ясно, что значит «при любых условиях».
250 байт на 1 миллионе соединений превращаются в 238 мегабайт памяти ;) Буферы, как минимум, — в
дополню сам себя: ядро выделяет структуру sk_buf для кадого соединения. В эту структуру входят указатели на буферы. Но размер самой структуры зависит от архитектуры и не превышает 250 байт. так что можно считать, что для каждого соединения выделяется 2 буфера (чтение и запись) + 250 байт. Разделите объём своей памяти на эти настройки и получите максимальное количество соединений для своей машины. Однако учтите, что софту так же требуется память ;)
вообще, оно ограничивается памятью системы, памятью выделенной сетевому стеку и количеством файловых дескрипторов в системе. Предел последнего определяется типом int в С:
Посмотреть бы на схему этой микросхемы (простите уж за тавтологию): любопытно, нет ли там отдельного контроллера и нескольких параллельно работающих чипов.
А теперь представьте, что у вас нет цветных кодов, а качество изображения не сильно лучше. И вам нужно найти эти объекты на снимке ;) На кадре хорошо виден пример подобной задачки. Хорошо, если есть запись предыдущих этапов и примерно понятно где искать. А если просто кадр…
Понравилось всё, кроме завершения: Земля тесная. Как бы пафосно ни звучало — судьба человечества за пределами Земли и солнечной системы.
Возможности для понимания мира мы только начали открывать. Мир — огромный массив данных. Мы до сих пор не можем обрабатывать хоть сколько-то сопоставимые объёмы. Большинство научных достижений — дело последних нескольких тысяч лет. Сравните это с временем существования видов существ, хотя бы. Я уж молчу про время геологических эпох.
«Потреблядство» нас, конечно, ждёт, но это далеко не венец нашего развития. Впереди нас ждёт очень интересное время.
ну это друзья как-то жестят: переходить на «нулевую» версию чего-либо всегда рисковано. А в случае с ядром они наверняка огребут кучу неприятностей.
Ну разве что новелловцы уверены во всех изменениях, сделанных в ядре… Может они сами большую часть и сделали…
Я думаю, это связано с тем, что андроид, в первую очередь — форк. У них есть стабильное дерево разработки в которое они вносят изменения. Очень тихо и спокойно. В отличии от настольных систем, ошибка с мобильными устройствами может стоить слишком дорого андроиду: кому нужен постоянно виснущий телефон, например?
Я пересобрав ядро несколько раз понял, что лучше сначала читать, потом пересобирать: часть опций доступны только при правильном сочетании других опций. Иногда эти сочетания не совсем очевидны.
а ufm я помню жаловался на реализацию bonding'а. Но я думаю, либо уже допилили, либо ещё допилят: ни один enterprise дистрибутив на ядра 3.х пока не перешёл.
даже если производитель поддерживает свой код сам, этот код, в какой-то мере, хранится в репозитории рядом с ядром. В данном случае речь скорее об управлении процессом разработки ядра в целом. Это огромная работа и совершенно неясно, кто этим будет заниматься в будущем.
Кроме того, производители железа предлагают очень много изменений в ядро: linux пишется далеко не только энтузиастами-одиночками. В разработке участвует огромное количество таких компаний как HP, IBM, Oracle и другие. И именно эти компании, на самом деле, вносят самый существенный вклад в развитие линукса.
а «Ксерокс», «Памперс» и «Коньяк» — торговые марки.
В целом, я, конечно, в курсе. И с большим уважением отношусь к GNU, но… но как привык давным-давно называть GNU/Linux просто Linux, так до сих пор и называю.
Не думаю, что попытка помочь вам будет уместная в комментариях…
Ядро 3.3 вы можете попробовать уже сейчас. Кроме того, в попытках обойти этот баг были предложены ряд workaround'ов, которые многим помогают.
это достаточно хитры баг: насколько я знаю, уже несколько раз сообщалось о нормализации ситуации с heavy IO, но каждый раз находилась проблемная комбинация железа и софта.
Сообщений об исправлении не видел в этот раз. Поживём — увидим.
в данном случае следует читать как «один из наиболее популярны», а не «лидирующий по рынку». У vmware есть свои «фишки», да. Но kvm вполне подходит для очень широкого круга пользователей.
Первые значения — сколько байт будет выделено под буферы при любых условиях.
Второе — при обычном течении «жизни».
Третье — сколько максимум может занять буфер.
Дополнительно можете почитать про tcp_mem, станет ясно, что значит «при любых условиях».
250 байт на 1 миллионе соединений превращаются в 238 мегабайт памяти ;) Буферы, как минимум, — в
Понятно, что максимальный размер буфера может быть больше. Но для записи слова ping хватит и 4к ;)
Возможности для понимания мира мы только начали открывать. Мир — огромный массив данных. Мы до сих пор не можем обрабатывать хоть сколько-то сопоставимые объёмы. Большинство научных достижений — дело последних нескольких тысяч лет. Сравните это с временем существования видов существ, хотя бы. Я уж молчу про время геологических эпох.
«Потреблядство» нас, конечно, ждёт, но это далеко не венец нашего развития. Впереди нас ждёт очень интересное время.
Ну разве что новелловцы уверены во всех изменениях, сделанных в ядре… Может они сами большую часть и сделали…
Кроме того, производители железа предлагают очень много изменений в ядро: linux пишется далеко не только энтузиастами-одиночками. В разработке участвует огромное количество таких компаний как HP, IBM, Oracle и другие. И именно эти компании, на самом деле, вносят самый существенный вклад в развитие линукса.
В целом, я, конечно, в курсе. И с большим уважением отношусь к GNU, но… но как привык давным-давно называть GNU/Linux просто Linux, так до сих пор и называю.
Ядро 3.3 вы можете попробовать уже сейчас. Кроме того, в попытках обойти этот баг были предложены ряд workaround'ов, которые многим помогают.
Сообщений об исправлении не видел в этот раз. Поживём — увидим.