- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
SLES это коробка, а не "ядро у пингвинов".
Объясняю что значит на практике в ядре по умолчанию. Не всегда получается выбрать желаемое, а часто трудящиеся не знают что выбрать. Заказал я однажды VPS сервер, выбрал Slackware пингвина и ext3 файловую систему, а хостер поставил Ubuntu пингвина и ReiserFS файловую систему, потому что такое сочетание выбирает большинство их пользователей.
кернел 2.4.15, в котором появился ext3.
У ext3 файловой системы тоже не все идеально,
хотя она журнальная и считается надежной.
Only metadata is journaled; file contents are not, but it's guaranteed that file contents are written to disk before associated metadata is marked as committed in the journal. This is the default on many Linux distributions. If there is a power outage or kernel panic while a file is being written or appended to, the journal will indicate the new file or appended data has not been "committed", so it will be purged by the cleanup process. (This appends and new files have the same level of integrity protection as the "journaled" level.) However, files being overwritten can be corrupted because the original version of the file is not stored. Thus it's possible to end up with a file in an intermediate state between new and old, without enough information to restore either one or the other (the new data never made it to disk completely, and the old data is not stored anywhere). Even worse, the intermediate state might intersperse old and new data, because the order of the write is left up to the disk's hardware.
Ext3 does not do checksumming when writing to the journal. If barrier=1 is not enabled as a mount option (in /etc/fstab), and if the hardware is doing out-of-order write caching, one runs the risk of severe filesystem corruption during a crash.[13][14] (This option is not enabled by default on almost all popular Linux distributions, and thus most distributions are at risk.)
Вы еще начните для комплекта утверждать, что контроллеры без write back cache лучше, потому что без него меньше шансов потерять данные.
В правильном железе порядок записи на носитель сохраняет порядок запросов на запись, то есть кэширование записи на носитель не влияет на целостность данных. Ошибки возникают только когда сам порядок запросов на запись позволяет нарушить целостность данных, что получается при асинхронном режиме согласно определению. А про неправильное железо и ext3 файловую систему уже написано выше, выгоды от хитростей в железе исчезают потому что приходится усложнять файловую систему.
Вопрос о пионерии остается в силе. Теперь уже в контексте - линукс хуже, потому что там больше шансов отстрелить себе ногу.
Там больше шансов наступить на скрытые грабли,
потому что пингвины хуже документированы, ...
В рамках топика - да, я уточнил, не актуально. В рамках холив^H^H^H^H^H предметного сравнения - почему нет?
Нельзя сравнивать новизну и стабильность, т.к. последняя идет в контексте уже существующих задачек, а первая влияет на выбор ОС под новые... и тем не менее возвращаясь к яндексовским патчам на сетку могу заметить, что одними ими не ограничивается дело, т.к. было еще пара-тройка полезных творений... и что? и вот мы приходим к тому, что это все нужно только тогда, когда хочется утилизировать дорогой сервер почти под самую завязку на задачах с линейной загрузкой. все тоже решается установкой сетевой карточки с TOE, что дает в разы больше преимуществ и даже не смотря на кривизну некоторых моментов в реализации стыковки с ОС.
Вот во фряшке есть слегка кривоватенький accf_http, а в линуксе появился deffered accept... про хронологию появления молчу, кажется она примерно такая же как и у kqueue и epoll, что наводит на мысль тупого передиралова... но в этом ничего плохого нет. Если рассмотреть принципы работы линуксового TCP_DEFER_ACCEPT и фряшного accf_http (или accf_data) то мы видем большую разницу. Во фряшке есть механизм позволяющий принимать HTTP запрос еще до момента срабатывания accept, а после усовершенствования модуля (это еще ряд полезных патчей) этот запрос можно проверять на валидность и многое другое сразу в kernel space. Надо заметить, что даже без усовершенствования модуля это очень хорошо разгружает различные серверные архитектуры на медленных конектах без дополнительного ПО. Ну пропускает он POST на прямую и что? ну небольшой проход напильничком и мы получаем sysctl-ку, которая устанавливает максимальный размер запроса принимаемого в kernel space.
Опенсорц опенсорцом, а зарабатывать на чем-то надо. Мне без разницы в какую ОС вкладывать деньги, но при разработке и доработке FreeBSD их нужно меньше. Если мы говорим про HTTP high load, то однозначно FreeBSD. Как минимум только из-за одного accf_http.
Далее предлагаю обратить внимание на netgraph, которым большинство не умеет пользоваться и по сей день. Представьте себе, что штатными средствами решается гигантская масса сетевых решений. Нужен 802.1q тунельчик? г-но вопрос... скриптик из нескольких строчек и вот он бриджик упаковывающий данные из одной сетевухи и выкидывающий к примеру по UDP в другую на другой конец света. Можно много типовых полезностей перечислять в том числе и под телефонию. Многие фаны линукса про это просто не знают... а это появилось еще хрен знает когда. Когда-то мы думали ставить ли RADовскую железку для проброса портов из региона до столицы или попробовать фряшный netgraph.... да по сей день на фряхе работает кажется.
ng_fec использует кто? подскажите мне пожалуйста аналог ng_fec под линукс?
kostich добавил 24.02.2008 в 13:22
а на FreeBSD - не знаю, когда я смотрю, как freebsdшники парятся с компиляцией и перекомпиляцией, ...
это не фриибсд-шники, а линуксоиды, которых заставили админить фрю.
Объясняю что значит на практике в ядре по умолчанию. Не всегда получается выбрать желаемое, а часто трудящиеся не знают что выбрать. Заказал я однажды VPS сервер, выбрал Slackware пингвина и ext3 файловую систему, а хостер поставил Ubuntu пингвина и ReiserFS файловую систему, потому что такое сочетание выбирает большинство их пользователей.
Это просто анекдот
В правильном железе порядок записи на носитель сохраняет порядок запросов на запись, то есть кэширование записи на носитель не влияет на целостность данных. Ошибки возникают только когда сам порядок запросов на запись позволяет нарушить целостность данных, что получается при асинхронном режиме согласно определению. А про неправильное железо и ext3 файловую систему уже написано выше, выгоды от хитростей в железе исчезают потому что приходится усложнять файловую систему.
Вы это тоже из практики работы с MS-DOS'ом взяли? В юниксах этот момент куда сложнее.
Резюмируем попроще - я считаю, что достаточно просто sync'ить данные, когда есть в этом необходимость, сохраняя производительность. Вы, как я понял, хотите неотложенную запись в любом случае, то есть перенесли проблему из юзерспейса в кернелспейс. А не хотите еще для комплекта, чтобы ядро интеллектуально делало локировки файлов вместо прикладного программиста?
Там больше шансов наступить на скрытые грабли,
потому что пингвины хуже документированы, ...
Это и называется - отстрелить себе ногу.
Про обширность документации на русском - надеюсь все таки, Вы авто не выбирали исходя из того, что в магазинах полно доков на русском, как чинить ВАЗ-ы.
А код открыт, куда уж больше документации.
Нельзя сравнивать новизну и стабильность, т.к. последняя идет в контексте уже существующих задачек, а первая влияет на выбор ОС под новые...
да помилуйте, какая новизна?
и тем не менее возвращаясь к яндексовским патчам на сетку могу заметить, что одними ими не ограничивается дело, т.к. было еще пара-тройка полезных творений... и что? и вот мы приходим к тому, что это все нужно только тогда, когда хочется утилизировать дорогой сервер почти под самую завязку на задачах с линейной загрузкой.
Вам ли не знать, что бывает, когда не просто хочется, а просто необходимо выжать все возможное из платформы.
все тоже решается установкой сетевой карточки с TOE, что дает в разы больше преимуществ и даже не смотря на кривизну некоторых моментов в реализации стыковки с ОС.
В линуксовом кернеле еще раньше появилась поддержка TSO для интеловских карт, года за 2-3 до поддержки TOE
Вот во фряшке есть слегка кривоватенький accf_http, а в линуксе появился deffered accept... про хронологию появления молчу, кажется она примерно такая же как и у kqueue и epoll, что наводит на мысль тупого передиралова... но в этом ничего плохого нет. Если рассмотреть принципы работы линуксового TCP_DEFER_ACCEPT и фряшного accf_http (или accf_data) то мы видем большую разницу. Во фряшке есть механизм позволяющий принимать HTTP запрос еще до момента срабатывания accept, а после усовершенствования модуля (это еще ряд полезных патчей) этот запрос можно проверять на валидность и многое другое сразу в kernel space. Надо заметить, что даже без усовершенствования модуля это очень хорошо разгружает различные серверные архитектуры на медленных конектах без дополнительного ПО. Ну пропускает он POST на прямую и что? ну небольшой проход напильничком и мы получаем sysctl-ку, которая устанавливает максимальный размер запроса принимаемого в kernel space.
>> как и у kqueue и epoll, что наводит на мысль тупого передиралова...
зато теперь приходится портировать epoll из линукса в freebsd заради всяких жав. :)
Все остальное, что вы описываете - ваши собственные ядерные наработки, так? Знаете, только по этой причине я не хочу с Вами спорить в этой ветке, просто по предположению, что Ваш выбор определен практикой, а не тем, что "на заборе написано".
Опенсорц опенсорцом, а зарабатывать на чем-то надо. Мне без разницы в какую ОС вкладывать деньги, но при разработке и доработке FreeBSD их нужно меньше. Если мы говорим про HTTP high load, то однозначно FreeBSD. Как минимум только из-за одного accf_http.
Порядки чисел можете озвучить?
UPD. не денег, порядки HTTP high load
Далее предлагаю обратить внимание на netgraph, которым большинство не умеет пользоваться и по сей день. Представьте себе, что штатными средствами решается гигантская масса сетевых решений. Нужен 802.1q тунельчик? г-но вопрос... скриптик из нескольких строчек и вот он бриджик упаковывающий данные из одной сетевухи и выкидывающий к примеру по UDP в другую на другой конец света.
Не совсем понял про .1q на другой конец света? у вас общий layer2 с этим другим концом света?
Подозреваю, Вы это о L2TP. И чего? Для линукса VPN-ы недостижимое дело?
ng_fec использует кто? подскажите мне пожалуйста аналог ng_fec под линукс?
в линуксе это называется bonding
$kernel_src/Documentation/networking/bonding.txt
Вообще не понимаю к чему это. В freebsd нет дискового кэширования? Или Вы принудительно свои fs с -o sync монтируете? Тогда снимаю шляпу перед Вашим стремлением к стабильности в ущерб эффективности. Неужели в freebsd нет вызовов sync()/fsync() и там единственный способ сбрасывать дисковые кэши - это их не использовать?
есть в фриибсд кэширование и есть оно как на чтение так и на запись... размер буфера фиксируется при старте и по умолчанию зависит от общего количества оперативы... исправить это можно выставлением пары параметров.
ps. любому фряшнику очень полезно прочитать man tuning
kostich добавил 24.02.2008 в 14:12
да помилуйте, какая новизна?
а разделение на продакшен и тестовое только у нас одних что ли есть? мы спать хотим спокойно.
Вам ли не знать, что бывает, когда не просто хочется, а просто необходимо выжать все возможное из платформы.
а я деньги считаю... мне эти тюнинги знаете ли где уже сидят... когда выжимают выжимают, а при реальном лоаде десяток паник подряд. зачем грузить под завязку? есть эксплутационный режим, под которой тестировали и есть небольшой запас... на задачах с линейной нагрузкой это прокатывает, на задачах с узкими местами само собой нет.
В линуксовом кернеле еще раньше появилась поддержка TSO для интеловских карт, года за 2-3 до поддержки TOE
а от TSO какая-то реальная польза есть?
>> как и у kqueue и epoll, что наводит на мысль тупого передиралова...
зато теперь приходится портировать epoll из линукса в freebsd заради всяких жав. :)
ну я верю что когда нибудь и native oracle под фрю будет...
Все остальное, что вы описываете - ваши собственные ядерные наработки, так? Знаете, только по этой причине я не хочу с Вами спорить в этой ветке, просто по предположению, что Ваш выбор определен практикой, а не тем, что "на заборе написано".
в большинстве случаев хватает всего дефолтного за что фряшка и ценна собственно... на этом я как раз и акцентирую, что вот дефолтных фишек хватает за глаза.
Порядки чисел можете озвучить?
отвечу абстрактно - в размере хороших по столичным меркам ЗП нескольким хорошим девелоперам.
Не совсем понял про .1q на другой конец света? у вас общий layer2 с этим другим концом света?
Подозреваю, Вы это о L2TP. И чего? Для линукса VPN-ы недостижимое дело?
Если бы всё решалось L2TP, то я бы про это не упоминал. Размер пакетика в 802.1q чуть больше и когда в качестве транспорта дают только ip по хорошему линку, а сетку нужно делать однородной, то приходится идти вот на такие ухищрения. В данном случае netgraph позволяет запихнуть всё as is в udp пакеты и выдуть из другого места.
ng_fec использует кто? подскажите мне пожалуйста аналог ng_fec под линукс?
в линуксе это называется bonding
$kernel_src/Documentation/networking/bonding.txt
почитал... в каких-то местах оно наверное даже удобнее.
kostich добавил 24.02.2008 в 14:19
UPD. не денег, порядки HTTP high load
UPD... ну представьте себе нашу специфику (см. в подписи)... сотни тысячь запросов в секунду... вот залез на две точки посмотреть стату - на одной 13406 активных сессий, на другой 28781... выходной однако... idle фактически... а в пиках мы раздаем до 100к ответов в секунду... на новой поделке, HTTP сервере со своим стеком, мы смогли выдать какую-то фантастическую цифру, но встал вопрос за правильность тестилки... скоро будет очередная стойка с пачкой серверов и там может быть что-то дотестим более правильно.
В ближайших планах параллельно построить CDN на 100Тб в мультихоумед AS с десятью точками по 1gb/s каждая. Как раз для тех кому нужно что-то раздавать в больших количествах большому количеству народа. И строить это будем на фряхе, т.к. все с ней в этом плане хорошо.
а разделение на продакшен и тестовое только у нас одних что ли есть? мы спать хотим спокойно.
Ну, все верно, и там, и там.
Про режим эксплуатации - ваш случай, полагаю, это все таки экстремальный режим эксплуатации.
а от TSO какая-то реальная польза есть?
На момент включения были цифры, по моему от 10% до 40% снижения нагрузки на cpu. Сейчас с ToE это уже, наверное, не актуально.
в большинстве случаев хватает всего дефолтного за что фряшка и ценна собственно... на этом я как раз и акцентирую, что вот дефолтных фишек хватает за глаза.
Та же история и в линуксе, но видите, тут, оказывается, некоторым в большинстве случаев системы на reiserfs ставят.
Если бы всё решалось L2TP, то я бы про это не упоминал. Размер пакетика в 802.1q чуть больше и когда в качестве транспорта дают только ip по хорошему линку, а сетку нужно делать однородной, то приходится идти вот на такие ухищрения. В данном случае netgraph позволяет запихнуть всё as is в udp пакеты и выдуть из другого места.
Понял, vpn lan-to-lan называется. Ну, openvpn - он в линуксе тоже успешно работает. Есть дистр такой zeroshell, он как раз под такие задачи заточен.
UPD... ну представьте себе нашу специфику (см. в подписи)... сотни тысячь запросов в секунду... вот залез на две точки посмотреть стату - на одной 13406 активных сессий, на другой 28781... выходной однако... idle фактически... а в пиках мы раздаем до 100к ответов в секунду... на новой поделке, HTTP сервере со своим стеком, мы смогли выдать какую-то фантастическую цифру, но встал вопрос за правильность тестилки... скоро будет очередная стойка с пачкой серверов и там может быть что-то дотестим более правильно.
Хотелось бы услышать в пакетрейте в контексте конфигурации платформы, особенно на форварде интересно.
И строить это будем на фряхе, т.к. все с ней в этом плане хорошо.
Без иронии - желаю подольше оставаться уверенным в этом. Себе желаю подольше быть уверенным в своем.
Вообще, мотив всего, чего я говорю (это предыдущим участникам ветки) - не стоит считать(особенно на основе голосований и всякой лирики), что линукс для пионеров, аfreebsd - для суровых мужчин. Это и есть самая настоящая пионерия.
Это просто анекдот
Вот такие они, дикие пингвины на воле, ...
Вы это тоже из практики работы с MS-DOS'ом взяли?
В юниксах этот момент куда сложнее.
А какое отношение имеет операционная
система к порядку действий железа?
Резюмируем попроще - я считаю, что достаточно просто sync'ить данные, когда есть в этом необходимость, сохраняя производительность. Вы, как я понял, хотите неотложенную запись в любом случае, то есть перенесли проблему из юзерспейса в кернелспейс.
Я хочу чтобы операционная система и железо писали на носитель в том порядке в котором я запрашиваю запись, этого вполне достаточно для целостности данных, по умолчанию у FreeBSD такое пожелание выполняется для метаданных, а запись в обычные файлы выполняется асинхронно для ускорения. А если делать sync но железо будет менять порядок записи на носитель, то целостность данных в общем случае может нарушиться например при внезапной остановке железа. Кстати если sync блокирует задачу до своего полного выполнения, то такие действия не годятся для изделий которые должны быстро отвечать на запросы, а если sync не блокирует задачу до своего полного выполнения, то задача не может быть уверена что целостность данных обеспечена.
Это и называется - отстрелить себе ногу.
Это называется футбол на минном поле, ...
А код открыт, куда уж больше документации.
Не всегда есть время играть в сапера, ...
А какое отношение имеет операционная
система к порядку действий железа?
здрасти, а для чего вообще операционная система?
Я хочу чтобы операционная система и железо писали на носитель в том порядке в котором я запрашиваю запись, этого вполне достаточно для целостности данных, по умолчанию у FreeBSD такое пожелание выполняется для метаданных, а запись в обычные файлы выполняется асинхронно для ускорения. А если делать sync но железо будет менять порядок записи на носитель, то целостность данных в общем случае может нарушиться например при внезапной остановке железа. Кстати если sync блокирует задачу до своего полного выполнения, то такие действия не годятся для изделий которые должны быстро отвечать на запросы, а если sync не блокирует задачу до своего полного выполнения, то задача не может быть уверена что целостность данных обеспечена.
Свалили в одну кучу все - работу в юзерспейсе, sync и fsync, работу fs, которых много и все работают по-разному, а некоторые еще и внутри себя позволяют разные принципы работы с журналами, довалили i/o планировщики, которых тоже несколько и с разными политиками, и еще да, давайте довалим туда работу firmware контроллера, если он у нас есть.
Это называется футбол на минном поле, ...
Не всегда есть время играть в сапера, ...
Ага, зато всегда есть время написать на форуме, что пингвины - глючное поделие
Если бы мы спорили о ЯП, мне бы пришлось выслушивать аргументы о том, что php/perl/python/прочие языки с динамическим выделением памяти лучше си, там меньше шансов наступить на мину/острелить себе ногу.
Ну, все верно, и там, и там.
Про режим эксплуатации - ваш случай, полагаю, это все таки экстремальный режим эксплуатации.
для нас это штатный...
На момент включения были цифры, по моему от 10% до 40% снижения нагрузки на cpu. Сейчас с ToE это уже, наверное, не актуально.
ну надо заметить что хорошие TOE карточки и стоят как половина сервера
Понял, vpn lan-to-lan называется. Ну, openvpn - он в линуксе тоже успешно работает. Есть дистр такой zeroshell, он как раз под такие задачи заточен.
опять мимо... но уже не суть.
Хотелось бы услышать в пакетрейте в контексте конфигурации платформы, особенно на форварде интересно.
ну скажу что на какие-то машины у нас до 1mpps-а в штатном режиме приходится... конфиги оглашать не буду, т.к. очень долго к этому шли и потратили на это очень много денег. ларчик простой, но нервной системы откушал прилично.
Без иронии - желаю подольше оставаться уверенным в этом. Себе желаю подольше быть уверенным в своем.
Вообще, мотив всего, чего я говорю (это предыдущим участникам ветки) - не стоит считать(особенно на основе голосований и всякой лирики), что линукс для пионеров, аfreebsd - для суровых мужчин. Это и есть самая настоящая пионерия.
ну все упирается же в деньги в итоге... для меня штат фряшников в разы приятнее чем пара линуксоидов, т.к. у первых мозги примерно одинаково работают, а у последних постоянные холивары между собой... при этом первым можно без каких либо граблей поручить поставить оракел на линукс, а последних надо долго убеждать прикоснуться к фряхе. а оно мне надо? конечно не надо... по этому и писал выше, что надо обсуждать в контексте конкретной задачи.
надо учитывать и стоимость обслуживания, форс-мажоры с персоналом и т.д... это вообще пипец какой-то, когда на линуксе... у меня вот один ответ по поводу фряхи "вон сервак, там все из портов собрано" и чел с первого дня вливается в команду... а чего я про линукс слышу "а где дока? а кто это собирал? за что ему тут деньги платили? я нашел дыру!!! почему эти патчи не стоят?"... "а с какими опциями тут апач компилили? почему логи не в том месте?" ... да у меня мозг плавится от этого начинает.
ps. еще бы нативный оракел и быструю жабу на фрю и цены бы ей не было... а так как говорится куда же без линукса то в хозяйстве. скоро линукс себе на десктоп поставлю... а что тут такого? фряшку под десктоп это же вообще гвоздь в голове надо иметь.
а для чего вообще операционная система?
Повторю другими словами с пояснением, какое
отношение имеет операционная система к порядку
действий железа на который она не может влиять?
With write back caching turned on by default, an ATA drive can signal the completion of writes more quickly than if it had to wait until the data was completely transferred to the disk media. However, in the even of a failure (such as power failure, hardware failure, etc.), data corruption may happen if the data on the disk cache has not been flushed out to the disk media. Another problem with ATA write back cache is that data may be flushed out to disks out-of-order, i.e., if block A arrives to cache before block B, block B may be flushed out to disk before block A. While turning the write back cache off for ATA disks will avoid data corruption problem, performance will degrade. In addition, the drives will be used in a less reliable mode, since ATA vendors do not certify the recovery of drives that deactivate write-back caching.
А усложнять файловую систему для того
чтобы избежать повреждения от хитростей
железа это отдельная печальная тема, ...
Свалили в одну кучу все - работу в юзерспейсе, sync и fsync, работу fs, которых много и все работают по-разному, а некоторые еще и внутри себя позволяют разные принципы работы с журналами, довалили i/o планировщики, которых тоже несколько и с разными политиками, и еще да, давайте довалим туда работу firmware контроллера, если он у нас есть.
По делу есть что написать? Или пингвины
как обычно не замечают леса за деревьями?
Если бы мы спорили о ЯП, мне бы пришлось выслушивать аргументы о том, что php/perl/python/прочие языки с динамическим выделением памяти лучше си, там меньше шансов наступить на мину/острелить себе ногу.
C тоже не идеал, декларации типа EQUIVALENCE в FORTRAN отсутствуют, родные non-preemptive со-программы типа как в MODULA-2 отсутствуют, поэтому приходится дорабатывать напильником, ...
C тоже не идеал, декларации типа EQUIVALENCE в FORTRAN отсутствуют, родные non-preemptive со-программы типа как в MODULA-2 отсутствуют, поэтому приходится дорабатывать напильником, ...
лан... valgrind спасет мир!
ps. но когда его в нормально виде под фряху допортируют? или я давно его не ставил?