Обнаружена D.o.S. для Tux-2.1.0-2

Те, кто использует tux давно перешли на более новые версии, в которой этой дырки нет.

Тут в форуме где-то один мужик жаловался именно на _это_ и что ресет только работает. Ему так никто и не казал че делать.

2Alant: а что есть камикадзе, которые используют его? ;)

>>а что есть камикадзе, которые используют его?
честно говоря таковых "живьем" не видел. но предположить что использовать его во внутренних сетях разумно.

А вот попой наружу выставлять... эт да , это точно камикадзе...
если такие есть, дайте урл пжалуста?

когда-то тут были разговоры про IIS6 и про то, как плоха идеология kernel-space http-сервера ^_^ хмм.. по-моему авторам веб-серверов акцент все-таки надо смещать не на скорость, а на функциональность. По-моему, пока кроме авторов Zope пока на эту тему не задумывался (хоть Zope и не совсем www-сервер...). А жаль.

2yakuza: эээ... простите, а как IIS относится к kernel-space??? Это обычный service, в терминологии *nix - daemon...

2ifconfig: объясни мне разумность использования его во внутренних сетях? В каких случаях это может быть оправдано? Я честно сказать не придумал - имхо если нужна производительность разумней купить машинку помощней...

Есть такая надежка, что со временем Tux заменит thttpd, через который все обычно гоняют картинки на загруженных серверах с динамикой.

2maxcom: видимо мне не приходилось сталкиваться с настолько нагруженной системой... Где почитать можно?
Но имхо никакое повышение производительности не оправдывает такое снижение надежности... ИМХО...

2Irsi: _по слухам_, в IIS6 часть кода будет работать в kernel-space, и про это здесь в свое время стоял флейм. Сейчас ситуация щекотливая, обзывать RedHat теми же словами, что и Microsoft, как-то у народа духу не хватает ^_^
Хотя идея kernel-space http-сервера, конечно, идиотская. То есть настоящих аргументов/исследований на эту тему я не видел. Думаю, что заставить людей поверить в необходимость такого экстрима можно только с помощью грязных маркетинговых уловок ^_^

2yakuza: хммм... будем смотреть, благо не очень долго осталось...:)
Я сейчас энергично думаю какие части httpd можно засунуть в kernel-space с целью повышения производительности и при этом не нанеся серьезного ущерба стабильности... Что-то пока в голову нихрена не приходит ;)

Isri, повышает, и очень значительно. Дело в том, что apache собранный с mod_php и mod_perl отъедает довольно много памяти в каждом процессе (т.к. во-первых они хранят в памяти откомпилированные странички, во-вторых они сами тянут за собой довольно много библиотек которые требуют память для настройки ссылок, да и вобще имеют механизны сохранения данных в памяти апача). Таким образом при нагрузке около 150-200 соединений (30-50 rq/sec) уже перестает хватать 1GB памяти чисто на апачей. Использование thttpd снижает загрузку на апач по примерно 80-120 соединений и тем самым экономит довольно много памяти. По моему опыту эта экономия в итоге выходит весьма значительной и существенно повышает возможности сервера. Кроме того, по моим испытаниям при передаче статического контента thttpd обгоняет apache даже на двухпроцессорной машине (это при том, что thttpd однозадачный)

2 Irsi: Ждет нас http.sys, который будет реализовывать соотв. сервис и кэширование. Если cache miss - будет запрашиваться IIS. Посмотрим что будет. Само собой все это дело можно будет отключить и использовать "просто" IIS6, который и сам по себе обещает быть ВЕСЬМА достойным web server'ом.

Апач на двухпроцовой тачке не слишком прибавляет в производительности, поскольку много времени тратится на переключения между процессами. имхо (и не только мое ;))

2Sergio: "поскольку много времени тратится на переключения между процессами"
По этому и разрабатывается Апач 2.0 где все будет сделано через нитки "и только линукс не получит прироста производительности из-за реализации ниток в этой ОС" (с) пересказ июньского (кажется) номера Линукс Журнал посвязенной Апачу.

> Кроме того, по моим испытаниям при передаче статического контента thttpd обгоняет apache

Добавлю ради объективности. На тех же задачах mathopd обгоняет thttpd процентов на 15.
А еще для полноты картины, полностью юзер-спейс вебсервер под названием X15
обходит на тех же задачах самого TUX'a... Беда не в том, что юзер-спейс демон
не может тягаться с ядреным, а в том, что в существующих обычных вебсерверах
кроме X15 нигде не реализованы те ускорятельные приемы и механизмы, которые существуют
в современном ядре 2.4. Если кто-то их реализует, то из этого получится непортабельный,
чисто линуксовый вебсервер. Зато очччень быстрый.

Кстати, про thttpd интересная фраза от Алана Кокса:
http://www.lib.uaa.alaska.edu/linux-kernel/archive/2001-Week-45/0577.html
Как раз по затронутой теме.

anonymous (*) (2001-11-07 00:36:50.0) Кто обещает? Бил Гейц? "Откиньтесь на спинку кресла и посмотрите, как Маздай все за вас сделает... Виндоза стала значительно лучше" - Установка Маздай Линолеум. Слушай Била больше

2maxcom: ну здесь уже затронули тему про треды...:) Имхо это единственный корректный выход в данной ситуации для *существенного* снижения нагрузки на память... Но как не смешно Ogr прав - для линукса от этого толка мало будет... Хотя если честно не особо смотрел что в 2.4 с тредами сделали - возможно для него некий толк будет... Для фряхи - будет, но тоже не слишком... Как не смешно набольший толк будет для апача под солярку и нтю, на х86 разумеется... :)
А вот эту фразу я не понял:
"Кроме того, по моим испытаниям при передаче статического контента thttpd обгоняет apache даже на двухпроцессорной машине (это при том, что thttpd однозадачный)"
Однозодачный это что в данном контексте? Однопоточный и не форкается? Тогда каким образом он использует второй проц? Свой механизм поддержки SMP? Если так - то упаси боже меня от таких продуктов...:)

2anonymous (*) (2001-11-07 00:36:50.0): драйвер http/https на уровне ядра? А типа все ASP/PHP/etc. в user space? Ооох... Не знаю...

Прошу прощения. Насколько я знаю есть такой WEB сервер AOLServer. Как раз мультипоточный и еще и заточенный под работу с БД. Есть в наличии кэш для статических страниц и отдельный кэш для функций Есть встроенные парсеры для Server-Pages(ADP- Aolserver Dynamic Pages) - аля РHP-server-page. Никто не пробовал? все собираюсь, да только руки не доходят. По-моему там немного другой подход чем в Апаче , и как мне кажется более удачный и с точки зрения производительности тоже. Так что мож не надо велосипед то изобретать?

Прохожий

> Имхо это единственный корректный выход в данной ситуации
> для *существенного* снижения нагрузки на память...

Имхо, сталкивание пустого флейма в сторону тредов и их незаменимости - естественная
реакция маздайцев. Последний бастион, так сказать, кхе, кхе ;)

Вам же достаточно привели примеров вебсерверов, которые значительно быстрее
и апача и IIS, и при этом обходятся нормально без преловутых threads.
Что вам еще нужно? Апачу нового поколения, я почти уверен, широко юзать не будут.
Ушло время, нет больше монополии, технологии апача устарели безнадежно.
Так что базар про новую инкарнацию апачей дял юниксов - пустое дело.

Irsi, идиот, иди хоть немного док почитай а потом возвращайся (а лучше не возвращайся вообще) - нефига здесь чат разводить. TUX для статики раза в 3 быстрее чем апач! И на каких-то русских серваках типа yandex или mail.ru он очень активно используется (или какой-то другой kernel-space httpd server, возможно для bsd - не помню).

Хех. > Точно не помню но какой используеться. Авторитетное заявление. :)

2shuras: ну действительно не помню, но факт что kernel space (и не помню под какую ОС - линух или бздю).

>Имхо, сталкивание пустого флейма в сторону тредов и их незаменимости - естественная
>реакция маздайцев. Последний бастион, так сказать, кхе, кхе ;)

Если бы трэды были не нужны, их бы в юнихах и не делали. Не находишь?
Другое дело, что они мало где нормально сделаны.

> Если бы трэды были не нужны, их бы в юнихах и не делали. Не находишь?

Ух, здорово сказано. Да, нахожу! Их в юниксах и не делают. Почти.
Нет в моем сервере ничего на тредах. Был один mysql, да и тот в расход пошел.
На постгрес заменен. Даже не знаю, зачем эти триды нужны ;)

>Ух, здорово сказано. Да, нахожу! Их в юниксах и не делают. Почти. >Нет в моем сервере ничего на тредах. Был один mysql, да и тот в >расход пошел. >На постгрес заменен. Даже не знаю, зачем эти триды нужны ;) ============================================================= Думаю что для малого числа процессов наверно это не страшно. А при приличной нагрузке могут быть проблемы.

Когда это может пригодится? Например когда необходимо нескольким процессам работать с одной и той же переменной. Для мультипроцессной реализации это делается с помощью shared memory с синхронизацие через семафоры. Типичным представителем такого софта есть СУБД Oracle.

Для нитей эта реализация просто выглядит более красивей и проще.

Хотя исходя из тенденций сегодняшнего дня, нити оказались не намного легче процессов, но все же легче. Следовательно в основном "важен интерфейс". Использование такого интерфейса облегчает программирование.

Да, сейчас вроде идет разговор о "микро-нитях".

>Когда это может пригодится? Например когда необходимо нескольким >процессам работать с одной и той же переменной. Для мультипроцессной >реализации это делается с помощью shared memory с синхронизацие через >семафоры.
>Для нитей эта реализация просто выглядит более красивей и проще.

Это каким же таким образом доступ к общей переменной (на запись, естественно) не будет посажен на семафор или в критическую секцию? Что с нитями, что с процессами делать это придется. А издержки на доступ к разделяемой памяти минимальны по сравнению с издержками на семафорные операции. Так что, для вашего примера разницы между нитями и процессами нет.

> умаю что для малого числа процессов наверно это не страшно.

Дело не в малои числе, а в малом весе этих процессов. Если этот вес достаточно мал, то
современный юникс может выдерживать тысячи таких процессов, а винда точно не
может этим похвастаться. Поэтому все ее прихлебатели поют диферамбы нитям, как
единственному и незаменимому средству.

Дело не в количестве. Но даже юникс ощутит разницу между тысячей процессов и тысячей трэдов.
Трэды придумали не в Windows, так что не надо.
Надо же, есть даже такая вещь, как posix threads.
И что, ты умнее тех, кто трэды создал? Они не незаменимы и не единственное средство, но удобное.
А ты просто твердолобость демонстрируешь, имхо.

2AC

Это каким же таким образом доступ к общей переменной (на запись, естественно) не будет посажен на семафор или в критическую секцию? Что с нитями, что с процессами делать это придется. А издержки на доступ к разделяемой памяти минимальны по сравнению с издержками на семафорные операции. Так что, для вашего примера разницы между нитями и процессами нет.

====================================================== Я не пишу на С сейчас и так детально не знаю. Я сейчас пользую Интерпритаторы ( Python,Perl )

Поэтому с моего субективного мнения скажу. Что даже если треды используют семафоры , все скрыто. И не надо изобретать велосипед.

Бред какой-то. Ничего там не скрыто. Ты можешь либо использовать синхронизацию, либо нет. Как, впрочем, и с разделяемой памятью. Никто тебя не заставляет использовать семафоры. Более того, семафор - всего лишь средство проверки возможности доступа к переменной. А вся логика реализуется в приложении. На системном уровне семафор ничего не запрещает.

Чем треды отличаются от группы процессов: структурами данных, которые для них поддерживает ядро. У процессов - общий сегмент текста (код приложения), свой стек, сегмент данных, файлы (стандартный ввод/вывод и все открытое), свои IPC структуры (в приципе это вместе с сокетами к файлам относится), что-то еще (может забыл что), да, сегмент данных тоже шарится по 'copy on write'. У тредов все общее кроме стека. Соответственно, когда будет наибольший выигрыш от использования тредов ? Тогда, когда будет максимально отношение "затраты на форк(создание структур)"/"объем (за неимением лучшего термина:) самостоятельной обработки или данных", т.е. в случае "классического" сервера: форк - обработка - стоп, тред заметного выигрыша не даст, а вот если форкаться на каждый асинк ввод/вывод, чтобы в это время иртерфейс на клики отзывался :), тогда да - процесс тяжеловато - лучше тред. Поэтому в винде все на тредах и построено, да, еще одно, винда ведь в дополнение к перечисленным структурам должна создавать еще кучу других - главное окно и т.д. и т.п., поэтому форк у нее ОЧЕНЬ тяжелый, и планка - когда следует переходить на треды еще сдвигается. Соответсвенно в виде - есть "классический" сервер, переходим на суперсервер (тредовый) - получаем ускорение ХХ%, делаем тоже самое в линухе - упс, намного меньше, и кричим "нити тяжелые" :) В чем неправ ?

> Но даже юникс ощутит разницу между тысячей процессов и тысячей трэдов.

Дык я не понял, в какую сторону он ощутит эту разницу - будет хуже или лучше?
По-моему практика дает однозначный ответ ;)

> Однопоточный и не форкается? Тогда каким образом он использует второй проц?

А никак не использует. Он однопоточный и сделан на неблокирующемся IO. Но мне это особо не мешало т.к. на той машине thttpd работал вместе с apache который значительно больше использовал проц (для исполнения php и mod_perl).

2maxcom: а к чему ты тогда упомянул двухпроцессорную машину? :)
Ладно, я вижу тута опять поднялся флейм "а нам эти треды нафиг не нужны!" Зелен виноград типа...;) Да, дайствительно, такая кособокая реализация тредов никому нафиг не нужна... К сожалению все фрюниксы страдают слабой реализацией тредов и как следствие - неэффективной поддержкой SMP... В коммерческих юниксах, которые изначально разрабатывались в расчете на SMP-архитектуры с этим жело обстоит гораздо лучше и те, кто работают с ними не кричат "да нафига нам эти треды!" - они прекрасно понимают нафига они им...:)

2ignite: ты не прав абсолютно во всем, начиная с того что в виндах программа обязана создавать главное окно :)
Контекст у треда существенно проще и меньше чем у процесса и следовательно на его переключение требы меньше ресурсов. Когда программа пишится без учета того что она будет работать на SMP, и соответственно форкается/пораждает треды относительно редко, разница действительно пребрежительно мала. Но как только начинается учитываться существование SMP возникает желание как можно сильней распаралелить задачу, для более эффективного использования преимуществ оной архитектуры, а следовательно - породить как можно больше тредов/процессов... И тут разме уже имеет существенное значение :)

> а к чему ты тогда упомянул двухпроцессорную машину? :)

Ирся, ты совсем умом одряхлел. Неужели непонятно? Маленький серверок с более
продвинутой технологией обработки запросов обошел апача, даже несмотря на то,
что апач задействовал два проца, а тот серверок (thttpd) только один.

2anonymous (*) (2001-11-08 00:43:47.0): действительно протормозил... Но пойми - повышать эффективность кода до бесконечности нельзя. Более того - эффективность кода обычно обратно пропорциональна кол-ву имеющихся в продукте фич... И в какой-то момент приходится жертвовать чачтью эффективности в пользу масштабируемости...

P.S. maxcom - вернули бы вы новость про Globe Produktive for Linux? Это не нас провоцировать - это линуксоидам порадоваться, ибо первый приличный офис под линукс портируют :)

To Irsi: >начинается учитываться существование SMP возникает желание как можно >сильней распаралелить задачу, для более эффективного использования >преимуществ оной архитектуры, а следовательно - породить как можно >больше тредов/процессов...

А вот ни хрена. Это все зависит от того, что в этих нитях делать. Наличие нитей побуждает к их интенсивному использованию, с другой стороны, редко когда имеется 'конфигурация данных', не требующая синхронизации, чем больше ты нитей нарожал, тем больше затрат на синхронизацию их общих данных, тем больше нитей отдыхает на входе в крит. секции или по семафорам -- со всеми вытекающими последствиями.
Поэтому 'параллелить задачу как можно сильнее' тоже нужно с умом. Иногда выгоднее создать несколько нитей/процессов потяжелее, чем рожать их в страшных количествах, даже и на SMP. Вот почему многие здесь и говорят про ненужность/вредность нитей -- потому что их наличие+'легковесность' побуждает программера создавать их на каждый чих -- в результате чего получается громоздский еле шевелящийся код, который большую часть времени проводит в блокировках.

2AC: ай, сдуру можно и х@й сломать, ктоб спорил...:) Видимо противники нити как сто раз и сломали и теперь обжегшись на молоке дуют на воду...;)

2 Irsi: нет, противники нитей, судя по этому обсуждению, видели тучу в основном виндузячего:) и особенно жабского кода, авторы которого используют нити чуть ли не как извращенный механизм вызова процедур -- а че, пусть, типа, работает 'параллельно', и synchronized везде налепим:)
Мало кто желает заморачиваться с pooling'ом нитей, с нормальным определением 'степени' параллелизма, с эффективной синхронизацией, etc. Поэтому, некоторые и считают, что что бы не дать людям возможность врезать себе молотком по лбу, лучше у них этот молоток отобрать. Ну, или сделать его неподъемным:)

2 AC: Во как. А Никлауса Вирта за это же самое (за то, что отобрал молоток, чтоб не поранились) линуксоиды (и не только) поливают дерьмом. Странный спор какой-то. На то, нужны нормальные трэды или не нужны ответ давно есть. И он положительный. И во всех системах, писаных не красноглазыми студентами, трэды есть и работают эффективно.

2Irsi: не Globe, а Gobe ;)
И кстати, изначально этот продукт был под BeOS, создатели которого слегка подвинулись на потоках :) [подливая масла в огонь:)]Там, если ты создаешь окно, то автоматически создается thread, обрабатывающий сообщения для этого окна. Такое вот интересное решение.

по-поводу тредов в комерческих Unix.

могу сказать только про HP-UX. Так вот треды там появились только в версии 11, которая вышла не так давно, а до этого ничего у них не было. Так что не надо ля-ля про комерческие Unix. У них тоже на все рук не хватает.

2anonymous (*) (2001-11-08 10:39:49.0)
не хыпуксом единым :) Можно назвать еще Digital UNIX, AIX. Спецификация POSIX threads была принята в 1995 году. И проблема тогда состояла не в отсутствии реализации threads, а в том, что разные производители предоставляли разные API. Проблема, как я понял, осталась и по сей день. Потому так часто используют библиотеки типа MIT threads, которые сглаживают шероховатости, касающиеся конкретных реализаций.

2 AC:
>Поэтому 'параллелить задачу как можно сильнее' тоже нужно с умом.

Ага.

>Иногда выгоднее создать несколько нитей/процессов потяжелее, чем >рожать их в страшных количествах, даже и на SMP.

В страшных количествах точно не стоит. Лучше необходимый минимум.

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

Профайлер юзать надо. Да и любой инструмент надо с умом юзать.
Так сделали Delphi, BCB - начали толпами сыпаться свистелки-перделки без реальной функциональности. Но есть и нормальные проги.
Так и с трэдами и/или форками. У меня куча потоков могла одновремменно исполнять один и тот же код. Для их разруливания мне удалось обойтись одной критической секцией, внутри которой всего две строки: закрытие файла и обнуление дескриптора. Нет 3, еще проверка одна. На блокировках тут точно ничего не тормозит. А тормозит на сетевых операциях, при этом процессора ест не более 1%.
Если сложно схему в голове прикинуть, можно воспользоваться например графической демонстрашкой сетей Петри и разрешить коллизии до написания кода.

>Дык я не понял, в какую сторону он ощутит эту разницу - будет хуже или лучше?

Имхо, от тысячи трэдов ему будет лучше, хотя опять же, зависит от дизайна.

>По-моему практика дает однозначный ответ ;)

Практика несколько однобокая получается.

А теперь представьте ситуацию: в юнихах трэды есть, а в виндах нету.
Я думаю, что в этом бы случае кричали трэды - рулез, не так ли? :)

>2anonymous (*) (2001-11-08 10:39:49.0)
>не хыпуксом единым :) Можно назвать еще Digital UNIX, AIX. >Спецификация POSIX threads была принята в 1995 году. И проблема >тогда состояла не в отсутствии реализации threads, а в том, что >разные производители предоставляли разные API. Проблема, как я >понял, осталась и по сей день. Потому так часто используют >библиотеки типа MIT threads, которые сглаживают шероховатости, >касающиеся конкретных реализаций.

>yakuza (*) (2001-11-08 11:01:36.0)


Eti (Digital UNIX, AIX ) mikrokernel OS .... V Otlichie LINUX,*BSD*

2kred: ну и кто создателям монолитных ядер доктор ? :)

2 Irsi

>2ignite: ты не прав абсолютно во всем, начиная с того что в виндах
>программа обязана создавать главное окно :)

OK, давай разберемся. Я не писал, что ПРОГРАММА ОБЯЗАНА создать
главное окно, винда сама внутри что-то там такое создает, я не
настолько знаком с внутренностями винды, чтобы спорить, но что-то
такое читал.

>Контекст у треда существенно проще и меньше чем у процесса и
>следовательно на его переключение требы меньше ресурсов. Когда

Контекст - это и есть то, что я описал, ну разве что еще регистры -
но это в обоих случаях одинаково.

>программа пишится без учета того что она будет работать на SMP, и
>соответственно форкается/пораждает треды относительно редко, разница
>действительно пребрежительно мала. Но как только начинается
>учитываться существование SMP возникает желание как можно сильней
>распаралелить задачу, для более эффективного использования
>преимуществ оной архитектуры, а следовательно - породить как можно
>больше тредов/процессов... И тут разме уже имеет существенное
>значение :)

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


Кто-нибудь подскажет, как это в шедулере линукса сделано ?

Флейм насчет ниток лучше прекратить за бессмысленностью.
Все равно останемся при своих.

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

Обратите внимание, на предложение намекнуть хотя бы, чем же нитки в
Линухе плохи, апологеты нитчатого подхода приводят такие аргументы (в
порядке частоты повторяемости):

1. Они основаны на вызове clone;
2. Это всем известно (вариант: Линус - козел);
3. На Линухе Жаба плохо бегает;
4. На Линухе плохо бегает программа XXX, специально затачивавшаяся под
нитки на Нте/Солярке.

Вроде, ничего не забыл.

Не только здесь, но и при обсуждении Оракла на Линухе vs NT, и на других
сайтах/форумах как русско- так и англоязычных я ни разу не видел иных
аргументов.

IMHO опровержение подобных аргументов есть удел людей, плохо понимающих свои
собственные мысли.

Примерно с той же пользой можно опровергать утверждение "ты - дурак"...