LINUX.ORG.RU
ФорумTalks

Технические преимущества современного Linux


0

0

Для спора с вендузятнегами требуются аргументы подобного рода. Бесплатность не в счет, надо их бить конкретными примерами где винда технически сливает или недоливает. Желательно со ссылками на тесты.

Как ни странно, флейма на эту тему много, а грамотного сравнения мало.

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

Как дела с кластерами, в чем там проблемы у винды?

Операции I/O в сети, на дисках?

То есть нужны конкретные аргументы с цифрами.

★★★★★
Ответ на: комментарий от iZEN

>А почему тогда люди воют из-за дикой фрагментации XFS на торрентах и медиафайлах?

Потому что, наверное, не измеряли фрагментацию на других FS :) А я - измерял. XFS - одна из лучших, если не лучшая. А то, что у XFS единственный под Linux работающий онлайновый дефраг и делает её единственным разумным выбором под торренты. Даже без учёта того, что она сама по себе очень быстра на чтении и, особенно, на чтении больших файлов. Собственно, ЕМНИП, я в той теме это всё и расписывал :)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

>Собственно, ЕМНИП, я в той теме это всё и расписывал :)

Нет, пардон, в какой-то из параллельных тем.

...

Тут ещё есть такая тонкость, что непонятно, как xfs считает уровень фрагментации. Тысяч 10 файлов нефрагментировано, но зато два новых, каждый из которых качался в десятки потоков - уфрагментированны в усмерть. По тысяче фрагментов. Как считать уровень фрагментированности? 0.01%? XFS по xfs_fsr в этом случае показывает уровень фрагментации в 98% :)

Вообще: http://balancer.endofinternet.net/munin/home/home/xfs_frag.html

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Под шлейфами понимается пошаговая прорисовка окон при движении под нагрузкой? Под аналогичными нагрузками в линухе окна вообще не двигаются ибо мышь не ездит :)

Reset ★★★★★
()
Ответ на: комментарий от KRoN73

>Тысяч 10 файлов нефрагментировано, но зато два новых, каждый из которых качался в десятки потоков - уфрагментированны в усмерть.

Неудивительно. Если есть онлайновый дефрагментатор (кстати, его вручную запускаешь или же он сам поднимается, когда приспичит?), то те 10 (больших!) файлов дефрагментированы, а кусочки недокачанных файлов так и лежат фрагментами. То есть, "разобранный" файл не будет фрагментирован, пока не завершится его полная запись? Для торрентов, особенно когда начинается закачка, это очень важно — они убивают производительность файловой системы в раз, если ФС (такая, как UFS2, например) не обеспечивает дефрагментацию (резервирование места) на лету.

iZEN ★★★★★
()
Ответ на: комментарий от Reset

>Под шлейфами понимается пошаговая прорисовка окон при движении под нагрузкой?

Не то, чтобы пошаговая... Фон просто вообще не стирается :)

>Под аналогичными нагрузками в линухе окна вообще не двигаются ибо мышь не ездит :)


Я таких нагрузок, значит, никогда не получал :) На многих машинах за многие годы. Кроме случаев, когда из-за того или иного глюка на машине, скажем, с гигом оперативки, в свопе оказывалось, например, 3Гб активно используемой памяти :)

Но даже вот при такой нагрузке: http://balancer.ru/img/forums/0608/OperaFoxMem.png система, хотя и притормаживала, но была вполне работоспособна :)

Так что, или ты сильно преувеличиваешь, или у тебя серёзные проблемы с железом (но тогда и винда тоже тормозила бы не меньше), или ты что-то сильно поломал в своей системе, а починить не можешь :)

...

Я знаю ситуации, когда Windows и ненастроенный Linux тормозят примерно поровну. Я знаю ситуции, когда Linux шустрее Windows, иногда - очень сильно (вот, буквально на этой машине - ссылки на истории выше. Что Windows, который настроить нелзя, что Linux до настроек - тормозили заметно (хотя и не до зависов), сейчас, после настроек, Linux очень плавно работает), но никогда не видел системы, где бы неполоманный Linux был тормознее Windows :)

KRoN73 ★★★★★
()
Ответ на: комментарий от Reset

Вообще ты где-то даже прав, с некотоыми дистрибутивами в настройках по умолчанию такое возможно, недавно я сдуру запустил преобразование фотографий командой convert *.tif *.jpg и оно у меня за полминуты отъело все ресурсы пользователя вплоть до замирания мышки.

(Вместо преобразования такая команда заставляет пытаться всё всосать в память и объединить). Правда при этом комп остался нормально виден по сети :) Лечится грамотной настройкой лимитов, чего в винде просто не сделать. Или сменой планировщика.

anonymous_incognito ★★★★★
()
Ответ на: комментарий от iZEN

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

Я несколько дней назад его в cron ночной прописал с ionice -c3. Отрабатывает минут за 5-10, нагрузки на систему не заметно. Выше ссылку на лог фрагментации дал, там видна работа :)

>то те 10 (больших!) файлов дефрагментированы, а кусочки недокачанных файлов так и лежат фрагментами


Тьфу, я протормозил. Да, я же сам цифры кидал: http://www.linux.org.ru/jump-message.jsp?msgid=4168426&cid=4168797 но их "не увидел" :)

Да, 11,5 тыс. фрагментов на 2 тыс. файлов.

>они убивают производительность файловой системы в раз


У меня, почему-то, не убивается ничего :) Даже когда идёт в таких условиях закачка на все 16Мбит (реальных 2Мбайт/сек).

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

> Так что, или ты сильно преувеличиваешь, или у тебя серёзные проблемы с железом (но тогда и винда тоже тормозила бы не меньше), или ты что-то сильно поломал в своей системе, а починить не можешь :)

Апгрейд памяти с 2х до 4х гигов "починил" мою систему, только вот на сколько хватит этого апгрейда пока не ясно.

Reset ★★★★★
()
Ответ на: комментарий от anonymous_incognito

Если виноват планировщик процессов (а это похоже на то), то уже ничего не поможет, его сменить нельзя.

Reset ★★★★★
()
Ответ на: комментарий от Reset

>Апгрейд памяти с 2х до 4х гигов "починил" мою систему, только вот на сколько хватит этого апгрейда пока не ясно.

Ну, я, вот, сейчас на 2Гб сижу :) Ещё и с кучей фоновых процессов.

На 4Гб я, вообще, /var/tmp/portage в tmpfs перевожу :)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

>Я несколько дней назад его в cron ночной прописал с ionice -c3. Отрабатывает минут за 5-10, нагрузки на систему не заметно.

Ясно. Значит "ручник" всё же нужен.
В UFS2 дефрагментация происходит на лету, какого-то дефрагментатора в виде запускаемой программы нету. Условия работы с UFS2 я уже приводил — повторяться не буду.

>Да, 11,5 тыс. фрагментов на 2 тыс. файлов.


То есть каждый файл имеет в "среднем по больнице" 5 фрагментов, разбросанных по сторонам диска.

>У меня, почему-то, не убивается ничего


Сколько торрентов (вернее — реальных файлов) на закачку стоит?

iZEN ★★★★★
()
Ответ на: комментарий от Reset

>Если виноват планировщик процессов (а это похоже на то)

Фигушки. Затыки обычно бывают на интенсивном IO. Я никогда не видел, чтобы затыкался Linux, который задавили процессы, не работающие с диском. Ну, разве что число процессов на многие тысячи идёт. До 1-2 тыс. процессов, грузящих систему на 100%, но без IO - не тормозят вообще.

Так что, если мышка застревает насмерть - то 99% за то, что проблема в кривом планировщике IO и в кривом же контроллере, а система ушла в свопинг.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Контроллер intel'евский у меня, когда на старой работе такая фигня была на nforce4, то я это списывал на кривой контроллер, но когда опять тоже самое на intel'е, то это явно что-то не то с системой.

Reset ★★★★★
()
Ответ на: комментарий от KRoN73

> Так что, если мышка застревает насмерть - то 99% за то, что проблема в кривом планировщике IO и в кривом же контроллере, а система ушла в свопинг.

У системы 4Гб памяти и своп отключён. Тем не менее, очень редко, но такие затыки бывают и действительно на дисковом I/O. NCQ включён и работает, возможно действительно контроллер кривоват.

anonymous_incognito ★★★★★
()
Ответ на: комментарий от iZEN

>Сколько торрентов (вернее — реальных файлов) на закачку стоит?

На раздаче - до сотни. На закачке - 5-10 штук обычно.

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous_incognito

>NCQ включён и работает

Я недавно с NCQ поиграл - не заметил какой-либо реакции в плане отзывчивости :)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

>На закачке - 5-10 штук обычно.

Это смешно. Нужно хотя бы 100-200 файлов на закачку (чтобы реально писались на диск их кусочки), вот тогда можно говорить о нагрузке.

iZEN ★★★★★
()
Ответ на: комментарий от Deleted

>Какой-то жалкий hostname поменять - и обязательно reboot.

Венда - одна большая перезагрузка.

anonumoustoo
()
Ответ на: комментарий от KRoN73

В моем ядре такого нет

io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Reset ★★★★★
()
Ответ на: комментарий от KRoN73

BFQ — это палеативное лечение. Всё дело в латентности оперативной памяти. DDR2 имеет в два-три раза большую задержку, чем обычная DDR.

iZEN ★★★★★
()
Ответ на: комментарий от KRoN73

>Я недавно с NCQ поиграл - не заметил какой-либо реакции в плане отзывчивости :)

Для NCQ нужно, чтобы поддержка обеспечивалась ВСЕМИ компонентами от диска до контроллёра и драйвера операционной системы. Если на каком-то участке "пути" что-то не так срослось, то NCQ будет всего лишь видимостью работы.

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

>Нужно хотя бы 100-200 файлов на закачку

Зачем столько файлов качать-то? Когда их смотреть потом?? :) 200 фильмов - это же полгода смотреть! :)

KRoN73 ★★★★★
()
Ответ на: комментарий от iZEN

>Всё дело в латентности оперативной памяти. DDR2 имеет в два-три раза большую задержку, чем обычная DDR.

И что? Какое отношение тип памяти имеет к замораживанию мыши? И, да, у меня DDR2 стоит. Никаких затыков :)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

+1, отлично написано/сказано

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

З.Ы. Крон,пасибо шо ты есть на ЛОРе )))

animechaos ★★
()
Ответ на: комментарий от KRoN73

>Зачем столько файлов качать-то? Когда их смотреть потом?? :) 200 фильмов - это же полгода смотреть! :)

Я обычно музыку качаю. MP3'ки по 10...20МБ занимают. Вот их и надо "смотреть".

iZEN ★★★★★
()
Ответ на: комментарий от anonymous_incognito

>> Так что, если мышка застревает насмерть - то 99% за то, что проблема в кривом планировщике IO и в кривом же контроллере, а система ушла в свопинг.

> У системы 4Гб памяти и своп отключён.

Это проблема в ДНК, которая приводит к thrashing в VM.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous_incognito

>> Так что, если мышка застревает насмерть - то 99% за то, что проблема в кривом планировщике IO и в кривом же контроллере, а система ушла в свопинг.

> У системы 4Гб памяти и своп отключён.

Это проблема в ДНК, которая приводит к thrashing в VM.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous_incognito

>> Так что, если мышка застревает насмерть - то 99% за то, что проблема в кривом планировщике IO и в кривом же контроллере, а система ушла в свопинг.

> У системы 4Гб памяти и своп отключён.

Это проблема в ДНК, которая приводит к thrashing в VM.

tailgunner ★★★★★
()

И что характерно - как обычно, начался серверный линуксячий срачь ...
На админской работе ведь свет клином не сошелся еще ?
Попробуйте выпустить документацию и развести печатную плату под Linux ...
Или, посчитайте время которое надо угрохать на освоение технологий работы
для написания встроенных приложений под Linux.
Отладка там fpga, логическое моделирование ... скорбно промолчим.
А звуковые нормальные редакторы есть по Linux ? (макеты и разовые потуги - не всчет).

Ограничить свои интересы до доступного в Linux - и полный порядок.

elipse ★★★
()
Ответ на: комментарий от anonymous_incognito

>> Так что, если мышка застревает насмерть - то 99% за то, что проблема в кривом планировщике IO и в кривом же контроллере, а система ушла в свопинг.

> У системы 4Гб памяти и своп отключён.

Вот так ошибки в ДНК ведут к thrashing :)

tailgunner ★★★★★
()
Ответ на: комментарий от elipse

> Или, посчитайте время которое надо угрохать на освоение технологий работы для написания встроенных приложений под Linux.

Расскажи нам об этом.

tailgunner ★★★★★
()

Для спора с вендузятнегами требуются аргументы подобного рода. ...

Давайте выясним сначала, из-за чего возник спор, а то спор ради спора интересен только на определённой стадии развития умственных способностей.

  • На своём домашнем компьютере все могут ставить себе что хотят. Меня это не касается. Точка.
  • Если всё же касается, значит ставлю то, что нахожу лучшим под определённый круг использования данного писюка данным юзером. Точка.
  • На работе могут ставить себе, мне что хотят. Меня это не касается. Точка.
  • Если всё же касается, значит ставят то, что является оптимальным вариантом под определённый круг использования данного писюка для решения рабочего задания, с беспроблемной кооперацией в пределах и за пределами места работы. Точка.

Какой спрашивается спор?

vOrOn
()
Ответ на: комментарий от iZEN

>Я обычно музыку качаю. MP3'ки по 10...20МБ занимают

Мухи отдельно, котлеты - отдельно.

1. Или mp3, или большие файлы. На mp3 фрагментации не бывает совсем.

2. Или сотня больших закачек, или сотня файлов. По сотне файлов я тоже многократно качал в рамках нескольких относительно небольших закачек.

В общем, ты уж там определись с условиями. А то то тёплое с мягким смешиваешь, то мух с котлетами.

KRoN73 ★★★★★
()
Ответ на: комментарий от elipse

>Попробуйте выпустить документацию и развести печатную плату под Linux ...

Когда говорят, что хорошее вино вкуснее палёной водки, это отнюдь не значит, что вино имеет смысл пить везде и всегда.

KRoN73 ★★★★★
()

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

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

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

vOrOn
()
Ответ на: комментарий от KRoN73

Что-то так тонко ... может, это была реклама самогона такая ? :)))

elipse ★★★
()

> Бесплатность не в счет, надо их бить конкретными примерами где винда технически сливает или недоливает. Желательно со ссылками на тесты

Скажи про порт на ARM и насладись очередным форком басни "лисица и виноград".

guest095433
()

> Вот, для начала по файловым системам хотелось бы четко выяснить на каких задачах вендузятнег будет три часа насиловать машину, а линуксоид все обтяпает за полчаса в лучшем виде и т.п.

http://httpfs.sourceforge.net/ пример как вытащить файл из образа на HTTP не скачивая его полностью.

guest095433
()
Ответ на: комментарий от tailgunner

> Это проблема в ДНК, которая приводит к thrashing в VM.

Ничего подобного, если памяти приложению не хватает, его планировщик просто грохает в итоге. Затык в этот момент возможен, но максимум на пару-тройку секунд.

Кстати, может пояснишь, что такого я неправильно делал, что ты докопался до ДНК?

anonymous_incognito ★★★★★
()
Ответ на: комментарий от anonymous_incognito

> Ничего подобного, если памяти приложению не хватает, его планировщик просто грохает в итоге.

Планировщик? O_o

> Кстати, может пояснишь, что такого я неправильно делал, что ты докопался до ДНК?

В Linux нельзя избежать пейджинга, никак. Поэтому, когда на безсвопной системе наблюдается недостаток памяти, VMM начинает пейджить _страницы кода_, потому что больше пейджить нечего. Если добавить к этому настройки overcommit по умолчанию, мы получим систему, которой невозможно пользоваться (это и называется thrashing). Причем часто (но не всегда) OOM killer в ситуацию не вмешивается, потому что VMM считает, что справится сам. Вот за отключение свопа без понимания последствий я и помянул твою ДНК.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Планировщик? O_o

Тьфу-ты.

> Поэтому, когда на безсвопной системе наблюдается недостаток памяти, VMM начинает пейджить _страницы кода_, потому что больше пейджить нечего.

Это нечто новенькое для меня. То есть как это, VM в ядре Linux вместо отказа в выдаче памяти просто так берёт и затирает вместо свопа на диске, страницы с кодом программ? O_o

anonymous_incognito ★★★★★
()
Ответ на: комментарий от anonymous_incognito

> То есть как это, VM в ядре Linux вместо отказа в выдаче памяти просто так берёт и затирает вместо свопа на диске, страницы с кодом программ? O_o

Затирает? O_O Приходит запрос на выделение памяти; свободной памяти нет; VMM нужно вытеснить из памяти какую-нибудь страницу. Так вот с отключенным свопом вытеснять анонимую память (== твои картинки) некуда; поэтому VMM вытесняет из памяти страницу кода (попросту выбрасывает ее, потому что код не меняется и его всегда можно подкачать из бинаря). В результате вполне может получиться так, кода X-сервера нет в памяти, и, когда ты шевелишь мышкой, VMM снова подкачивает его с диска (выбрасывая по ходу другой код). Если на пальцах, это и называется thrashing %)

tailgunner ★★★★★
()
Ответ на: комментарий от xnick

>как только будет писать вирусы под линукс экономически целесообразно - вирусы появятся. есть организмы, которые верят в отсутвие дыр в опенсорсе. блаженны верующие =)

Насчет дыр. Не исключено, что линукс спасает от нашествия вирусов зоопарк всего и вся.

Dudraug ★★★★★
()
Ответ на: комментарий от tailgunner

> Если на пальцах, это и называется thrashing %)

Не знал, я думал, что исполняющийся код никто из памяти не выкидывает, если нет свопа. Если в самом деле так, оно выглядит очень сомнительным поведением, по крайней мере на дестопе в обычном рабочем окружении, если нет задачи пытаться любой ценой "удержаться на плаву"

anonymous_incognito ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.