Re: kernel downgrade (2.6-2.4) and raid1
Hello! On Sat, Dec 22, 2007 at 03:33:38PM +0200, Michael Shigorin wrote: А I/O эти ваши программы много делают? (и если много -- то на ext3?) Не много, по сути только логгинг (но в режиме debug, т.к. довольно активный. Но я не сказал бы что есть нагрузка на диск). На ext3. У меня-то на 2.6 всё хорошо, но сборки нормальные, а не самопал. Сборки ядра или софта? Если ядра, то дистрибутивные ядра в первую очередь пробовались, конечно. Если хочешь, можно попробовать проверить. Тяжело. Проблема выскакивает в неопределенный момент на короткий промеждуток времени. Может быть раз в сутки, а может быть раз в трое суток. Может под нагрузкой, а может и без особой нагрузки. -- WBR, Alexander Burnos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Epiphany. Отключить загрузку картинок
23.12.07, Сергей С.[EMAIL PROTECTED] написал(а): Добрый день. Возможен ли сабж? Возможет. Помогает поиск в about:config по слову image. И гугль тоже помогает. -- WBR, Max Vasin JID: [EMAIL PROTECTED]
linux-vserver + nvidia driver
Как уже писал, завёл vserver на рабочей машине, чтобы поиграться, научиться. Планировал на хосте работать в GNOME, на гостях играться. Система Etch + ядро с backports 2.6.22-3-vserver-686. При попытке установить драйвер nvidia NVIDIA-Linux-x86-169.07-pkg1.run машина вешается (kernel panic). Вроде при попытке загрузки модуля nvidia. Сейчас поставил 2.6.22-3-686 (без vserver) - все ок. Это конечно изврат наверно, но всё же интересно, эта связка в принципе нерабочая или как-то можно их подружить? -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openvz, vserver
Для администрирования сайта жизненно необходим рутовый доступ? Дожили... Рутовый доступ был необходим для решения проблем с сервером. В частности, мне нужно было поправить настройки апача - а сделать это я не мог. Установить доступ на запись к нужному конфигу сайта учетной записи пользователя и дать права на перезапуск своего сайта. Не знаю, можно ли в апач перезапустить отдельный сайт, но надеюсь, да (иначе странный выбор для хостинга, имхо). В самом деле, отличный пример - зачем настраивать sudo, если можно поставить виртуалку и дать к ней рутовый доступ. Нет, серьезно, блестящий пример непотребного использования виртуализации. sudo даст мне доступ к другим ресурсам в системе, что мне совершенно не надо. Так это как настроить. sudo собственной инициативой не обладает, к счастью.
Re: OpenVZ, VServer и полудесяток
В сообщении от Monday 24 December 2007 10:15:15 Mikolaj Golub написал(а):
On Sun, 23 Dec 2007 18:05:23 +0300 Alexey Pechnikov wrote:
AP P.S. Утилита rm отвратительно работают с большим числом файлов в
директории. Я AP пишу свои скрипты на tcl, которые выполняют то же самое
на несколько порядков AP быстрее. В то же время ls работает нормально, не
знаю, в чем проблема. На AP примере миллиона файлов: rm /test_100/*
думает часами и зверски насилует AP винт, в то время как на тикле foreach
fn [glob /test_100/*] {file delete AP $fn} работает две-три минуты и
почти не шелестит винтом. Посмотрите, может, и AP у вас где подобные
грабли закопаны.
Сдается мне, что ту проблема с работой glob в шелле а не с утилитой rm. И
вообще использование * при работе с миллионом файлов в shell кажется мягко
говоря странным. Неужели не нарвались на Argument list too long? Ну да,
возможно еще один повод похаять shell и порадоваться за тикль, но к
сожалению без шелла никуда :-(
--
Mikolaj Golub
Из шелла писал _одну_ строку - rm /test_100/*. И
аргумент /test_100/* всего один, откуда возьмется Argument list too
long? Если бы в тикле оно не работало, да, полез бы в исходники rm
разбираться, а так - вот именно, что повод похаять, но исправлять этот самый
rm надобности нет. Вообще говоря, наличие указанного бага в
узкоспециализированном языке (шелл) и отсутствие в языке с широкой областью
применения (тикль) заставляет подумать о том, что пора шелл выкинуть на
свалку. Благо заменить есть чем - функциональных языков хватает.
Re: openvz, vserver
Alexey Pechnikov wrote: Для администрирования сайта жизненно необходим рутовый доступ? Дожили... Рутовый доступ был необходим для решения проблем с сервером. В частности, мне нужно было поправить настройки апача - а сделать это я не мог. Установить доступ на запись к нужному конфигу сайта учетной записи пользователя и дать права на перезапуск своего сайта. Не знаю, можно ли в апач перезапустить отдельный сайт, но надеюсь, да (иначе странный выбор для хостинга, имхо). Вы не знаете, можно ли перезапустить отдельный сайт в апаче и беретесь судить о том, что можно применять в хостинге, а что - нет? И как много у вас таких теоретических суждений, выдаваемых с видом эксперта? Вот давайте вы сначала немного изучите предметную область, получите минимальный _практический_ опыт администрирования публично доступных серверов, а потом уже обсудим вкус устриц, ок? -- Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openvz, vserver
On Monday 24 December 2007 12:24, Alex Kuklin wrote: Вы не знаете, можно ли перезапустить отдельный сайт в апаче и беретесь судить о том, что можно применять в хостинге, а что - нет? И как много у вас таких теоретических суждений, выдаваемых с видом эксперта? Вот давайте вы сначала немного изучите предметную область, получите минимальный _практический_ опыт администрирования публично доступных серверов, а потом уже обсудим вкус устриц, ок? Не хотел переходить на личности, но я очень хорошо помню момент, когда г-н Печников стал писать в рассылку. Поток флейма сингулярно подскачил в несколько раз. -- Макс Дмитриченко -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openvz, vserver
В сообщении от Monday 24 December 2007 12:24:24 Alex Kuklin написал(а): Alexey Pechnikov wrote: Для администрирования сайта жизненно необходим рутовый доступ? Дожили... Рутовый доступ был необходим для решения проблем с сервером. В частности, мне нужно было поправить настройки апача - а сделать это я не мог. Установить доступ на запись к нужному конфигу сайта учетной записи пользователя и дать права на перезапуск своего сайта. Не знаю, можно ли в апач перезапустить отдельный сайт, но надеюсь, да (иначе странный выбор для хостинга, имхо). Вы не знаете, можно ли перезапустить отдельный сайт в апаче и беретесь судить о том, что можно применять в хостинге, а что - нет? И как много у вас таких теоретических суждений, выдаваемых с видом эксперта? Вот давайте вы сначала немного изучите предметную область, получите минимальный _практический_ опыт администрирования публично доступных серверов, а потом уже обсудим вкус устриц, ок? Полагаете, мои мысли насчет неуместного использования виртуальных машин ошибочны в силу того, что я не знаю реализацию виртуального хостинга в апаче? Речь шла о том, что в данном указанном вами примере можно обойтись без виртуализации. И без рутового доступа. К реализации виртуального хостинга в апаче все это не имеет ни малейшего отношения (можно запустить и не один экземпляр апач, с разными скриптами запуска и настроить sudo, это далеко не всегда уместно, но _возможно_; заметим, что в виртуальном окружении и так будет свой экземпляр веб-сервера, только что выиграем от самого виртуального окружения?). P.S. Я не из вредности, действительно интересно услышать некоторые общие соображения о _необходимости_ виртуализации. Пока что вижу только, что в некоторых частных ситуациях таким путем можно частично защититься от кривости применяемых решений. И то это помощь для хостера, а не для клиентов - потому что ресурс все равно ляжет, но в контексте виртуальной машины, что защитит лишь пользователей других ресурсов. Скажем так, не антибиотик, а ампутация.
Re: openvz, vserver
Alex Kuklin wrote: Alexey Pechnikov wrote: Установить доступ на запись к нужному конфигу сайта учетной записи пользователя и дать права на перезапуск своего сайта. Не знаю, можно ли в апач перезапустить отдельный сайт, но надеюсь, да (иначе странный выбор для хостинга, имхо). Вы не знаете, можно ли перезапустить отдельный сайт в апаче и беретесь судить о том, что можно применять в хостинге, а что - нет? И как много у вас таких теоретических суждений, выдаваемых с видом эксперта? Вот давайте вы сначала немного изучите предметную область, получите минимальный _практический_ опыт администрирования публично доступных серверов, а потом уже обсудим вкус устриц, ок? Это Вы лихо взяли, ведь изучать-то нечего, LAMP на свалке, shell на свалке, быдлоадмины в пути на свалку, остается сплошная теория из серии: http://static.oper.ru/data/gallery/l1048751000.jpg -- maxym -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OpenVZ, VServer и полудесяток
24.12.07, Alexey Pechnikov[EMAIL PROTECTED] написал(а): Из шелла писал _одну_ строку - rm /test_100/*. И аргумент /test_100/* всего один, Как это один? Вы с оффтопиком не путаете? Разворачивание аргументов осуществляется оболочкой (shell), а не программой. -- WBR, Max Vasin JID: [EMAIL PROTECTED]
Re: openvz, vserver
Alexey Pechnikov wrote: В сообщении от Monday 24 December 2007 12:24:24 Alex Kuklin написал(а): Alexey Pechnikov wrote: Для администрирования сайта жизненно необходим рутовый доступ? Дожили... Рутовый доступ был необходим для решения проблем с сервером. В частности, мне нужно было поправить настройки апача - а сделать это я не мог. Установить доступ на запись к нужному конфигу сайта учетной записи пользователя и дать права на перезапуск своего сайта. Не знаю, можно ли в апач перезапустить отдельный сайт, но надеюсь, да (иначе странный выбор для хостинга, имхо). Вы не знаете, можно ли перезапустить отдельный сайт в апаче и беретесь судить о том, что можно применять в хостинге, а что - нет? И как много у вас таких теоретических суждений, выдаваемых с видом эксперта? Вот давайте вы сначала немного изучите предметную область, получите минимальный _практический_ опыт администрирования публично доступных серверов, а потом уже обсудим вкус устриц, ок? Полагаете, мои мысли насчет неуместного использования виртуальных машин ошибочны в силу того, что я не знаю реализацию виртуального хостинга в апаче? Я полагаю, что ваше суждение мало связано с реальной жизнью, а применимо лишь к некоторому сферическому серверу в вакууме. И предлагаю вернуться к разговору о том, как, зачем и почему можно|нужно использовать виртуализацию после обретения вами практического опыта работы с реальными серверами. -- Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OpenVZ, VServer и полудесят ок
Alexey Pechnikov пишет:
В сообщении от Monday 24 December 2007 10:15:15 Mikolaj Golub написал(а):
On Sun, 23 Dec 2007 18:05:23 +0300 Alexey Pechnikov wrote:
AP P.S. Утилита rm отвратительно работают с большим числом файлов в
директории. Я AP пишу свои скрипты на tcl, которые выполняют то же самое
на несколько порядков AP быстрее. В то же время ls работает нормально, не
знаю, в чем проблема. На AP примере миллиона файлов: rm /test_100/*
думает часами и зверски насилует AP винт, в то время как на тикле foreach
fn [glob /test_100/*] {file delete AP $fn} работает две-три минуты и
почти не шелестит винтом. Посмотрите, может, и AP у вас где подобные
грабли закопаны.
Сдается мне, что ту проблема с работой glob в шелле а не с утилитой rm. И
вообще использование * при работе с миллионом файлов в shell кажется мягко
говоря странным. Неужели не нарвались на Argument list too long? Ну да,
возможно еще один повод похаять shell и порадоваться за тикль, но к
сожалению без шелла никуда :-(
--
Mikolaj Golub
Из шелла писал _одну_ строку - rm /test_100/*. И
аргумент /test_100/* всего один, откуда возьмется Argument list too
long? Если бы в тикле оно не работало, да, полез бы в исходники rm
Тебе ж говорят, rm тут ни при чём! Звёздочку для него шелл раскрывает -
http://gazette.linux.ru.net/rus/articles/abs-guide/x12531.html
разбираться, а так - вот именно, что повод похаять, но исправлять этот самый
rm надобности нет. Вообще говоря, наличие указанного бага в
узкоспециализированном языке (шелл) и отсутствие в языке с широкой областью
применения (тикль) заставляет подумать о том, что пора шелл выкинуть на
свалку. Благо заменить есть чем - функциональных языков хватает.
Ой-ёй, зачем такие экстремистские высказывания?
Не умеешь в баше скрипты готовить - пиши в тикле или в чём другом, зачем
орать при этом - пора шелл выкинуть?
--
С уважением, Любимец Андрей Алексеевич
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OpenVZ, VServer и полудесяток
Alexey Pechnikov - debian-russian@lists.debian.org @ Mon, 24 Dec 2007
12:19:52 +0300:
AP P.S. Утилита rm отвратительно работают с большим числом файлов в
директории. Я AP пишу свои скрипты на tcl, которые выполняют то же самое
на несколько порядков AP быстрее. В то же время ls работает нормально, не
знаю, в чем проблема. На AP примере миллиона файлов: rm /test_100/*
думает часами и зверски насилует AP винт, в то время как на тикле foreach
fn [glob /test_100/*] {file delete AP $fn} работает две-три минуты и
почти не шелестит винтом. Посмотрите, может, и AP у вас где подобные
грабли закопаны.
Сдается мне, что ту проблема с работой glob в шелле а не с утилитой rm. И
вообще использование * при работе с миллионом файлов в shell кажется мягко
говоря странным. Неужели не нарвались на Argument list too long? Ну да,
возможно еще один повод похаять shell и порадоваться за тикль, но к
сожалению без шелла никуда :-(
--
Mikolaj Golub
AP Из шелла писал _одну_ строку - rm /test_100/*. И
AP аргумент /test_100/* всего один, откуда возьмется Argument list too
AP long?
Из мана на используемый шелл, а что?
Не, судя по отсутствию Argument list too long этот rm - builtin, и
шелл, как следствие, скорее всего, busybox... И именно в его исходники
и надо смотреть.
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
Если ничто уже не помогает, прочтите же, наконец, инструкцию!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel downgrade (2.6-2.4) and raid1
У сб, 2007-12-22 у 15:33 +0200, Michael Shigorin пише: On Fri, Dec 21, 2007 at 01:25:31PM +0200, Alexander Vlasov wrote: Хм. У меня одна машина на 2/4 до сих пор живет по той же причине -- всплески LA до 50 на ядрах 2.6 (правда 2.6.8, этч не пробовал). И там не Java, там самописная C++-программа. Так что джава не при чем. Если будет солюшен -- я тоже буду благодарен. А I/O эти ваши программы много делают? (и если много -- то на ext3?) Много. на xfs. У меня-то на 2.6 всё хорошо, но сборки нормальные, а не самопал. У меня тоже нормальные. Если хочешь, можно попробовать проверить. Что? Я у себя буду проверять в ближайшее даст бог время, мигрируя на etch эту машину. Или сразу строя дубликат на etch'е, потому как на той мне железо не нравится. -- Alexander Vlasov ZULU-UANIC JID: zulu at jabber.kiev.ua -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel downgrade (2.6-2.4) and raid1
У пт, 2007-12-21 у 23:58 +0300, Alexander GQ Gerasiov пише: На Fri, 21 Dec 2007 13:37:28 +0200 Alexander Burnos [EMAIL PROTECTED] записано: Hello! On Fri, Dec 21, 2007 at 01:25:31PM +0200, Alexander Vlasov wrote: Хм. У меня одна машина на 2/4 до сих пор живет по той же причине -- всплески LA до 50 на ядрах 2.6 (правда 2.6.8, этч не пробовал). У меня проблема проявляется на всех 2.6 ядрах, на родном 2.6.8 sarge в том числе. 23е ядро пробовал? там сильно другой шедулер. Нет. Так как эта задача обслуживает клиентов, то всплеск LA до пары десятков эффективно приводит к отпаданию нескольких сотен из тысячи приконнекченных 8( Так что поле для экспериментов ограничено. -- Alexander Vlasov ZULU-UANIC JID: zulu at jabber.kiev.ua -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openvz, vserver
У сб, 2007-12-22 у 17:31 +0300, Alexey Pechnikov пише: Если администрить вместо одной ОС десяток виртуальных ОС, тут человеческих ошибок администрирования станет столько, что уже без разницы, насколько исходно прямое средство виртуализации. Нормальный софт и так хорошо виртуализуется, например, в постгресе можно создавать отдельные кластеры, но чаще слышу о запуске виртуалок с единственным кластером на дефолтовом порту... Веб-сервера, включая пресловутый апач (если им еще кто-то пользуется) тоже виртуальный хостинг поддерживают. И т.д. Не исключаю, что может возникнуть необходимость в виртуализации ОС, но не у всех и не всегда. Не знаю что и сказать. Недетская каша. -- Alexander Vlasov ZULU-UANIC JID: zulu at jabber.kiev.ua -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Антивирусная про верка http и ftp траффи ка
Я эту задачу попытался решить таким образом: Построена цепочка из squid, dansguardian и havp. (почему так сложно? софтина dansguardian отличный фильтр запросы (достаточно просто усложнить скачивание *.exe), но в связке с clamav-daemon очень сильно кушает проц, и требует наличия parenty proxy. Включить ему squid вмест parent как-то избыточно, да и havp куда-то надо подключить). Такая конфигурация работает достаточно устойчиво, но , как оказалось, для антивирусной проверки ftp-траффика для havp тоже нужен parent! ;) Вот я и размышляю, как поступить: - добавить в цепочку ещё 1 squid - найти другой ftp/http прокси (3proxy например - но его в репозитории нет, а хотелось бы обойтись стандартным набором софта ) Или кто-то знает другие решения? -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Кто хочет дебианов ских футболок может пр иобресть
На Mon, 24 Dec 2007 10:18:37 +0300 Grey Fenrir [EMAIL PROTECTED] записано: В Mon, 24 Dec 2007 09:22:52 +0300 Max Dmitrichenko [EMAIL PROTECTED] пишет: On Sunday 23 December 2007 21:23, andrey i. mavlyanov wrote: Оные наконец-то появились в линуксцентре Размеры: XL: http://www.linuxcenter.ru/shop/gifts/t-shirts/futbolka_debian_XL/ L: http://www.linuxcenter.ru/shop/gifts/t-shirts/futbolka_debian_L/ M: http://www.linuxcenter.ru/shop/gifts/t-shirts/futbolka_debian_M/ S: http://www.linuxcenter.ru/shop/gifts/t-shirts/futbolka_debian_S/ Чтобы получить семипроцентную скидку до 1-го января в поле сертификат для скидки ввести LINUX2007 (без кавычек). Сворачивайтесь, футболисты. А то скоро начнут предлагать шлюх владеющих командной строкой Сударь является модератором списка? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-vserver + nvidia driver
На Mon, 24 Dec 2007 10:42:44 +0200 Покотиленко Костик [EMAIL PROTECTED] записано: Как уже писал, завёл vserver на рабочей машине, чтобы поиграться, научиться. Планировал на хосте работать в GNOME, на гостях играться. Система Etch + ядро с backports 2.6.22-3-vserver-686. При попытке установить драйвер nvidia NVIDIA-Linux-x86-169.07-pkg1.run Ну так ССЗБ. машина вешается (kernel panic). Вроде при попытке загрузки модуля nvidia. Сейчас поставил 2.6.22-3-686 (без vserver) - все ок. Это конечно изврат наверно, но всё же интересно, эта связка в принципе нерабочая или как-то можно их подружить? В принципе рабочая связка - ядро с vserver из testing и nvidia из моего репозитория (в секции бэкпорт лежит версия, работающая со старым xorg) Подозреваю, что с ядром с бэкпортом тоже должно работать. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OpenVZ, VServer и полудесяток
В сообщении от Sunday 23 December 2007 21:38:05 Artem Chuprina написал(а): MS Кажется, сперва думал, что полдюжины, потом заюзал пальцы для учёта MS и оказалось, что вторая рука не нужна :-) Я до дюжины на одной считаю. :-) А почему 12, а не 31? :^) (2^5=32) -- WestCall SPb dept. Phone: +7-(812)-320-0500 ext. 4580 e-mail: [EMAIL PROTECTED]
Re: странности с 2.6.18-5-686
На Sun, 23 Dec 2007 01:00:46 +0200 Dmitry Nezhevenko [EMAIL PROTECTED] записано: On Sat, Dec 22, 2007 at 11:36:25PM +0300, Олег Анисимов wrote: Евгений М. Солодухин пишет: в любом случае - собрать новое ядро недолго. 2.16.23.8 дома себя прекрасно чуйствует. Блин. и где вы такие ядра-то берете? Или все дело в Машине Времени? ;) 1. http://packages.debian.org/sid/linux-image-2.6.23-1-686 2. http://kernel.org + make-kpkg 2.16.23 не нашел. =P -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OpenVZ, VServer и полудесяток
Dmitry V. Agalakov - debian-russian@lists.debian.org @ Mon, 24 Dec 2007
16:21:22 +0300:
MS Кажется, сперва думал, что полдюжины, потом заюзал пальцы для учёта
MS и оказалось, что вторая рука не нужна :-)
Я до дюжины на одной считаю. :-)
DVA А почему 12, а не 31? :^)
DVA (2^5=32)
Неудобно. Я пробовал. Операция увеличения на 1 (AKA посчитать
следующий) слишком сложная.
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
Рюкзак не пересобирают, рюкзак укладывают! (c)Руна
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OpenVZ, VServer и полу десяток
On 2007.12.24 at 16:21:22 +0300, Dmitry V. Agalakov wrote: В сообщении от Sunday 23 December 2007 21:38:05 Artem Chuprina написал(а): MS Кажется, сперва думал, что полдюжины, потом заюзал пальцы для учёта MS и оказалось, что вторая рука не нужна :-) Я до дюжины на одной считаю. :-) А почему 12, а не 31? :^) (2^5=32) Считать в двоичной системе на пальцах - нужна очень высокая координация и заученный автоматизм. А до 12 (по костяшкам) старинный метотд. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-vserver + nvidia driver
В Пнд, 24/12/2007 в 16:50 +0300, Alexander GQ Gerasiov пишет: На Mon, 24 Dec 2007 10:42:44 +0200 Покотиленко Костик [EMAIL PROTECTED] записано: Как уже писал, завёл vserver на рабочей машине, чтобы поиграться, научиться. Планировал на хосте работать в GNOME, на гостях играться. Система Etch + ядро с backports 2.6.22-3-vserver-686. При попытке установить драйвер nvidia NVIDIA-Linux-x86-169.07-pkg1.run Ну так ССЗБ. Очень интересно. А что такое ССЗБ? машина вешается (kernel panic). Вроде при попытке загрузки модуля nvidia. Сейчас поставил 2.6.22-3-686 (без vserver) - все ок. Это конечно изврат наверно, но всё же интересно, эта связка в принципе нерабочая или как-то можно их подружить? В принципе рабочая связка - ядро с vserver из testing и nvidia из моего репозитория (в секции бэкпорт лежит версия, работающая со старым xorg) Подозреваю, что с ядром с бэкпортом тоже должно работать. Можно узнать адрес Вашего репозитория? -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-vserver + nvidia driver
На Mon, 24 Dec 2007 16:33:19 +0200 Покотиленко Костик [EMAIL PROTECTED] записано: В Пнд, 24/12/2007 в 16:50 +0300, Alexander GQ Gerasiov пишет: На Mon, 24 Dec 2007 10:42:44 +0200 Покотиленко Костик [EMAIL PROTECTED] записано: Как уже писал, завёл vserver на рабочей машине, чтобы поиграться, научиться. Планировал на хосте работать в GNOME, на гостях играться. Система Etch + ядро с backports 2.6.22-3-vserver-686. При попытке установить драйвер nvidia NVIDIA-Linux-x86-169.07-pkg1.run Ну так ССЗБ. Очень интересно. А что такое ССЗБ? Сам себе злобный буратина :) машина вешается (kernel panic). Вроде при попытке загрузки модуля nvidia. Сейчас поставил 2.6.22-3-686 (без vserver) - все ок. Это конечно изврат наверно, но всё же интересно, эта связка в принципе нерабочая или как-то можно их подружить? В принципе рабочая связка - ядро с vserver из testing и nvidia из моего репозитория (в секции бэкпорт лежит версия, работающая со старым xorg) Подозреваю, что с ядром с бэкпортом тоже должно работать. Можно узнать адрес Вашего репозитория? gq.net.ru/debian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openvz, vserver
Я полагаю, что ваше суждение мало связано с реальной жизнью, а применимо лишь к некоторому сферическому серверу в вакууме. И предлагаю вернуться к разговору о том, как, зачем и почему можно|нужно использовать виртуализацию после обретения вами практического опыта работы с реальными серверами. Пока я не увидел, ради чего использовать виртуализацию на своих серверах. Вы упомянули про ограничение ресурсов (про разграничение прав доступа не будем, это уж кому как нравится реализовывать) - для ограничения ресурсов одного приложения создавать виртуальную машину мне кажется неоправданным. Если я не путаю, в солярисе для этих надобностей есть так называемые контейнеры, и вроде даже их начинали портировать под линукс. Также в ядрах выше 2.6.21 какие-то игры с планировщиками идут, может быть, необходимое ограничение ресурсов можно реализовать через задание приоритета процесса? Дисковое пространство ограничить можно несколькими способами, это проблем не вызывает, остается ввод-вывод и ресурсы процессора и памяти. Допустимый объем ОЗУ многим приложениям можно указывать (или это можно на уровне системы сделать?). Или вы просто ставите виртуальную машину, не разбираясь, есть ли альтернативные пути решения?
Re: openvz, vserver
Это Вы лихо взяли, ведь изучать-то нечего, LAMP на свалке, shell на свалке, быдлоадмины в пути на свалку, остается сплошная теория из серии: http://static.oper.ru/data/gallery/l1048751000.jpg Так все от задач зависит. Но почему-то независимо от моих или ваших задач рекламируется один путь - виртуализация, один веб-сервер - апач, одна БД - мускул и так далее (немного утрирую, но тем не менее что-то похожее наблюдается). Пусть будет виртуализация, но не потому, что модно, а потому, что это единственный способ решить определенные задачи. Но где взять информацию, какие именно задачи решаются только таким образом и где найти другие пути решения? Когда я говорю о том, что выбор одного решения в роли священной коровы приводит к множеству негативных последствий, речь идет о рассмотрении альтернатив, но ни одной альтернативы хотя бы за этот год я в рассылке не видел. Вот решил спросить - вдруг кто подскажет. Пока еще надеюсь на это.
Re: openvz, vserver
On Monday 24 December 2007 18:09, Alexey Pechnikov wrote: Пока я не увидел, ради чего использовать виртуализацию на своих серверах. Не используй! Виртуализация - это хрень и забудь про нее. Точка. -- Макс Дмитриченко -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openvz, vserver
On Mon, Dec 24, 2007 at 09:49:09AM +0300, Alexey Pechnikov wrote: Я не разрушать предлагал, а подумать. Эффективность сильно зависит от видения ситуации в целом, а технологии это лишь средство решения задач. Задачи нужно суметь поставить, вместо беготни за разрекламированными технологиями (когда-то была ява с ее виртуальной машиной, теперь вот виртуализация...). Ваш пример выше очень даже хорошо подтвердил мою точку зрения. JVM и OpenVZ/vserver/xen/whatever - вещи перпендикулярные и решают совершенно разные задачи. -- WBR, Dmitry signature.asc Description: Digital signature
Re: OpenVZ, VServer и полудесяток
On Mon, 24 Dec 2007, Victor Wagner wrote: Считать в двоичной системе на пальцах - нужна очень высокая координация и заученный автоматизм. А до 12 (по костяшкам) старинный метотд. О! А это как? У меня и костяшек 5...
Re: Выбор звуковой карт ы для Linux
Andrey Tataranovich - debian-russian@lists.debian.org @ Sun, 23 Dec 2007 11:56:08 +0200: AT Мне критично следующее: AT 1) наличие аппаратного микширования AT 2) хорошая поддержка стерео системы 2.0 AT и как бонус не помешает запись звука (Microphone, Line-In) У меня в desktop дома стоит ESI Juli@, в целом доволен как слон. Не работает только «программная коммутация каналов». Да, используется она восновном как «источник» на уши. Пока разводим оффтоп, может кто посоветует колонки, а? 2.0, больше не надо, бюджет — $100-$150. -- .''`. Kirill A. Korinskiy [EMAIL PROTECTED] : :' : proud (maniac)? (developer|hacker) `. `'` http://catap.ru/ - +7 (916) 3-604-704 - xmpp:[EMAIL PROTECTED] `- Debian - when you have better things to do than fixing systems -- madduck pgpAWvC5C2Sdq.pgp Description: PGP signature
Re: Выбор звуковой карты для Linux
Kirill A. Korinskiy пишет: Andrey Tataranovich - debian-russian@lists.debian.org @ Sun, 23 Dec 2007 11:56:08 +0200: AT Мне критично следующее: AT 1) наличие аппаратного микширования AT 2) хорошая поддержка стерео системы 2.0 AT и как бонус не помешает запись звука (Microphone, Line-In) У меня в desktop дома стоит ESI Juli@, в целом доволен как слон. Не работает только «программная коммутация каналов». Да, используется она восновном как «источник» на уши. Пока разводим оффтоп, может кто посоветует колонки, а? 2.0, больше не надо, бюджет — $100-$150. microlab solo 2 или 5 -- Александр Вайтехович e-mail: [EMAIL PROTECTED] icq: 168712946 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openvz, vserver
Alexey Pechnikov wrote: Я полагаю, что ваше суждение мало связано с реальной жизнью, а применимо лишь к некоторому сферическому серверу в вакууме. И предлагаю вернуться к разговору о том, как, зачем и почему можно|нужно использовать виртуализацию после обретения вами практического опыта работы с реальными серверами. Пока я не увидел, ради чего использовать виртуализацию на своих серверах. Вы упомянули про ограничение ресурсов (про разграничение прав доступа не будем, это уж кому как нравится реализовывать) - для ограничения ресурсов одного приложения создавать виртуальную машину мне кажется неоправданным. Если я не путаю, в солярисе для этих надобностей есть так называемые контейнеры, и вроде даже их начинали портировать под линукс. Если вы потрудитесь изучить вопрос, прежде чем рассуждать, то вы увидите, что OpenVZ как раз и реализует модель паравиртуализации, при которой расходы на создание каждого нового VE мизерны. Это не создание полной виртуальной машины со своим процессором, памятью и железом, а разграничение на уровне (грубо говоря) вызовов ядра. -- Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OpenVZ, VServer и пол удесяток
On 23-Dec-2007, Alexey Pechnikov wrote: P.S. Утилита rm отвратительно работают с большим числом файлов в директории. Я пишу свои скрипты на tcl, которые выполняют то же самое на несколько порядков быстрее. В то же время ls работает нормально, не знаю, в чем проблема. Кстати да, искал альтернативу rm/ls/mv, неужели лучше писать самому в скриптах ? сложностей не составило. Если вы системные скрипты пишете на bash, то я вам просто сочувствую. На bash я делаю только скрипты для /etc/init.d/ Временами в рассылке пробегают темы о различных извращениях для ценителей bash, но это, видно, не для меня, читаю (интересно же) с ужасом :-) Для init.d bash как раз не рекомендуются, есть специальные шеллы с минимизацией количества форков при загрузке.. Насчет сочувствия - сочувствую тем кто не читает вообще никакие доки, даже howto и faq, не умеет пользоваться гуглом и думает что в этом виноват bash. Эта проблема есть вообще _везде_ - ограничение на длину команды(без которого было бы всё _намного_ хуже), ядро эти * не понимает, bash заменяет такие маски на полный список соотв. файлов, длина команды получается адской. Решение: find /test/test_1/ -type f |xargs rm Немного более кошерно: find /test/test_1/ -type f -print0 |xargs -0 rm -f Вообще это может и сам find: find /test/test_1/ -type f -delete Но xargs более универсальная вещь. Глубина рекурсии для поиска по умолчанию не ограничена, чтобы не трогать подкаталоги: find /test/test_1/ -type f -maxdepth=1 |xargs rm Насчет вашего варианта на тикле - он хуже(съест дофига ram, если файлов много), и явно медленнее решения с find. и, кстати, на bash, вы могли бы написать аналогично: cd /test/test_00/ for f in $(ls ) do rm $f done Если не хочеться менять каталог - добавьте путь в ls и rm или используйте файл: for f in $(find /test/test_000/ -type f); do rm $f; done Но это очень не эффективно - по форку на файл. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openvz, vserver
On 24-Dec-2007, Alexey Pechnikov wrote: Полагаете, мои мысли насчет неуместного использования виртуальных машин ошибочны в силу того, что я не знаю реализацию виртуального хостинга в апаче? В силу того, что вы не имеете представления о программировании и о безопасности. Ошибки есть везде, они могут быть в ядре, в каких-то других запущенных демонах, в библиотеках. Причины их могут лежать на аппартном уровне и программно вообще не обходиться. Поэтому виртуализация появилось ещё в середине прошлого века, хотя тогда это обходилось несоизмеримо дороже чем сейчас. Если нужна безопасность, главное правило - держать разные части системы на разных машинах, и, лучше, не подключенных к интернету, а запросы пропускать через риверс-прокси. База данных точно должна быть видна только из локальной сети. Речь шла о том, что в данном указанном вами примере можно обойтись без виртуализации. И без рутового доступа. заметим, что в виртуальном окружении и так В экземпляров веб-сервера будет не один и не два, а намного больше, и запускаете их не вы. будет свой экземпляр веб-сервера, только что выиграем от самого виртуального окружения?). Мы ничего не потеряем, но сильно повысим надежность и безопасность. vserver, например, рекомендуется использовать даже если разделения не требуется - с одним экземпляром ос где крутится всё что надо, на голой хост-системе. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OpenVZ, VServer и полу десяток
On Mon, Dec 24, 2007 at 01:42:54PM +0300, Artem Chuprina wrote: Alexey Pechnikov - debian-russian@lists.debian.org @ Mon, 24 Dec 2007 12:19:52 +0300: AP Из шелла писал _одну_ строку - rm /test_100/*. И AP аргумент /test_100/* всего один, откуда возьмется Argument list too AP long? Из мана на используемый шелл, а что? Не, судя по отсутствию Argument list too long этот rm - builtin, и шелл, как следствие, скорее всего, busybox... И именно в его исходники и надо смотреть. Во-первых, ограничение размера аргументов -- это ограничение execve(), статус возврата E2BIG. В линуксе традиционно был лимит в 128KB. Шелл сначала раскручивает *, затем делает fork() и попытку execve(/bin/rm). Во-вторых, я сильно сомневаюсь, что есть нормальный (не-busybox'овый) шелл, у которого rm -- встроенная команда. Потому что исторически у rm есть немало опций, разбирать которые шеллом замучаешься... Да и нет, собственно, причин делать rm встроенным. А тормоза у Печникова, наверное, из-за того, что шелл * пакует в монолитную строку через realloc(), а тикл пользуется чанковыми строками. Но и это не предел оптимизации. Думаю, perl с unlink() в реверсном цикле уделает этот тикль как бог черепаху... :-) -- Eugene Berdnikov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OpenVZ, VServer и полудесяток
В сообщении от Tuesday 25 December 2007 00:31:28 Eugene Berdnikov написал(а): А тормоза у Печникова, наверное, из-за того, что шелл * пакует в монолитную строку через realloc(), а тикл пользуется чанковыми строками. Но и это не предел оптимизации. Думаю, perl с unlink() в реверсном цикле уделает этот тикль как бог черепаху... :-) Не совсем понял, как это объясняет жуткое скрежетание винтом от команды rm? Мало того, что тормозит, еще и винт мордует. Притом так, что я уже не рискую подобные тесты запускать, не хочется винт угробить.
Re: openvz, vserver
В сообщении от Monday 24 December 2007 21:01:11 Alex Kuklin написал(а): Alexey Pechnikov wrote: Я полагаю, что ваше суждение мало связано с реальной жизнью, а применимо лишь к некоторому сферическому серверу в вакууме. И предлагаю вернуться к разговору о том, как, зачем и почему можно|нужно использовать виртуализацию после обретения вами практического опыта работы с реальными серверами. Пока я не увидел, ради чего использовать виртуализацию на своих серверах. Вы упомянули про ограничение ресурсов (про разграничение прав доступа не будем, это уж кому как нравится реализовывать) - для ограничения ресурсов одного приложения создавать виртуальную машину мне кажется неоправданным. Если я не путаю, в солярисе для этих надобностей есть так называемые контейнеры, и вроде даже их начинали портировать под линукс. Если вы потрудитесь изучить вопрос, прежде чем рассуждать, то вы увидите, что OpenVZ как раз и реализует модель паравиртуализации, при которой расходы на создание каждого нового VE мизерны. Это не создание полной виртуальной машины со своим процессором, памятью и железом, а разграничение на уровне (грубо говоря) вызовов ядра. Во сколько раз возрастает количество вызовов при названном подходе? Each VPS performs and executes exactly like a stand-alone server; VPSs can be rebooted independently and have root access, users, IP addresses, memory, processes, files, applications, system libraries and configuration files. Если возрастает незначительно, согласен. Но пока что я конкретных цифр не видел, может, плохо искал. Мои соображения следующие: раз дублируются все системные вещи (не знаю, как грамотно сказать), то нагрузка от каждого виртуального окружения по порядку величины равна нагрузке от основной системы. Возможно, для вас это мелочь и четыре-восемь процессорных ядер на сервере вместо одного-двух есть разумная плата за удобство.
Re: GPG error
On Saturday 22 December 2007 05:12, Artem Chuprina wrote: А тут надо запустить aptitude update -v и посмотреть, что он скажет. Он расскажет подробнее об ошибке. В aptitude update -v релевантная часть выглядит так: W: GPG error: http://www.debian-multimedia.org etch Release: Следующие подписи неверные: BADSIG 07DC563D1F41B907 Christian Marillat [EMAIL PROTECTED] W: Вы можете запустить 'apt-get update' для исправления этих ошибок При этом Уже установлена самая новая версия debian-multimedia-keyring Про бекпорты теперь почему-то ничего не говорит. -- Yours, Mikhail Ramendik
Re: OpenVZ, VServer и пол удесяток
On 25-Dec-2007, Alexey Pechnikov wrote: Тогда по идее rm -rf /test/test_1/ должно работать быстро, поскольку список файлов не передается Здесь-то что мешает? Надо пройти по всем файлам рекурсивно, сделать unlink, если какой-то процесс держит файл открытым, удаление будет откладываться, как и удаление каталогов к которых он находится. что наверняка и проиходит. обходных путей несколько, в разной степени корретных, но я сомневаюсь, что тикл их использует. Разве что если эти файлы от как сам и держит:) Решение: find /test/test_1/ -type f |xargs rm Немного более кошерно: find /test/test_1/ -type f -print0 |xargs -0 rm -f Вообще это может и сам find: find /test/test_1/ -type f -delete Но xargs более универсальная вещь. Глубина рекурсии для поиска по умолчанию не ограничена, чтобы не трогать подкаталоги: find /test/test_1/ -type f -maxdepth=1 |xargs rm Насчет вашего варианта на тикле - он хуже(съест дофига ram, если файлов много), и явно медленнее решения с find. Интересно, откуда это следует. Буду пробовать. Сдается мне, что если запускаю один интерпретатор тикля, то это будет не медленнее варианта с find, который тоже еще надо проверить по скорости. у find всё ok со скоростью, особенно если перенаправлять стандартный вывод в другую программу. xargs будет формировать из ст.входа куски максимальной длины и запускать с поочередно rm со след.куском __поиск и удаление работают паралельно__, расход оперативной памяти будет ограничен, а если rm не будет успевать удалять файлы то find`у придется его ждать. а последовательный вариант - это сформировать весь массив, ждать когда отработает find, интерпретировать его вывод, потом запускать rm для каждого файла. Идея понятна. Только на тикле это рабочее решение, а на баше - лишь пример. на баше это тоже рабочее решение. просто крайней неоптимальное. Хотя если в используемом шёлле подобные команды встроены, то и проблемы быть не должно. а) проблема с unlink`ами никуда не делась б) лучше использовать xargs. это один из случаея, когда xargs очень рулит. в) оптимальные задачи для шелла вообще это перенаправление выхода и входа. фактически накладных расходов минимум - несколько системных вызовов и дальше всё делает ядро. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openvz, vserver
Alexey Pechnikov wrote: Во сколько раз возрастает количество вызовов при названном подходе? Each VPS performs and executes exactly like a stand-alone server; VPSs can be rebooted independently and have root access, users, IP addresses, memory, processes, files, applications, system libraries and configuration files. Если возрастает незначительно, согласен. Но пока что я конкретных цифр не видел, может, плохо искал. Мои соображения следующие: раз дублируются все системные вещи (не знаю, как грамотно сказать), то нагрузка от каждого виртуального окружения по порядку величины равна нагрузке от основной системы. Возможно, для вас это мелочь и четыре-восемь процессорных ядер на сервере вместо одного-двух есть разумная плата за удобство. Вот статейка есть на тему производительности: http://www.hpl.hp.com/techreports/2007/HPL-2007-59.pdf -- WBR, Ivan S. Dubrov signature.asc Description: OpenPGP digital signature
Re: openvz, vserver
Alexey Pechnikov пишет: Это Вы лихо взяли, ведь изучать-то нечего, LAMP на свалке, shell на свалке, быдлоадмины в пути на свалку, остается сплошная теория из серии: http://static.oper.ru/data/gallery/l1048751000.jpg Так все от задач зависит. Но почему-то независимо от моих или ваших задач рекламируется один путь - виртуализация, один веб-сервер - апач, одна БД - мускул и так далее (немного утрирую, но тем не менее что-то похожее наблюдается). Пусть будет виртуализация, но не потому, что модно, а потому, что это единственный способ решить определенные задачи. Но где взять информацию, какие именно задачи решаются только таким образом и где найти другие пути решения? Когда я говорю о том, что выбор одного решения в роли священной коровы приводит к множеству негативных последствий, речь идет о рассмотрении альтернатив, но ни одной альтернативы хотя бы за этот год я в рассылке не видел. Вот решил спросить - вдруг кто подскажет. Пока еще надеюсь на это. Алексей, посмотри на виртуализацию с другой стороны -- не всегда твоя задача сможет загрузить имеющееся в твоём распоряжении железо, а если она использует его менее чем на 10%, то, возможно,сам задумаешься - чем бы его нагрузить, а может - начальство за тебя подумает ;-) Тут хочешь-не хочешь - вспомнишь и про виртуализацию.Особенно, если придётся делить ресурсы сервера с кем то ещё. -- С уважением, Любимец Андрей Алексеевич -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openvz, vserver
Алексей, посмотри на виртуализацию с другой стороны -- не всегда твоя задача сможет загрузить имеющееся в твоём распоряжении железо, а если она использует его менее чем на 10%, то, возможно,сам задумаешься - чем бы его нагрузить, а может - начальство за тебя подумает ;-) Тут хочешь-не хочешь - вспомнишь и про виртуализацию.Особенно, если придётся делить ресурсы сервера с кем то ещё. Сразу предвижу возражение: зачем под задачу, которая требует 486 процессор покупать Коре Дуо? Пора завязывать толочь воду в ступе-то. -- С уважением, Константин Матюхин
L192WS widescreen
Превед всем. У меня возникла проблема, собрал другу компьютер с сабжевым монитором, поставил на него Etch 4.0 без обновлений. Монитор отказался включаться в режиме 1440х900. В интернете прочитал, что широкоформатные мониторы лечат обычно вставкой соответствующего Modeline. В xorg.conf внёс такие изменения Section Monitor ... UseModesMyModes0 EndSection Section Modes IdentifierMyModes0 Modeline 1440x900 106.50 1440 1488 1536 1840 900 902 905 947 -HSync +Vsync EndSection ... Section Screen ... SubSection Display Viewport 0 0 Depth 24 Modes1440x900 1280x1024 1024x768 EndSubSection Включать нужный видео режим монитор всё равно отказался, аргументируя это следующей выдержкой из Xorg.0.log (II) I810(0): Monitor0: Using hsync range of 30.00-83.00 kHz (II) I810(0): Monitor0: Using vrefresh range of 56.00-75.00 Hz (II) I810(0): Not using mode 1440x900 (no mode of this name) (II) I810(0): Not using built-in mode 1920x1440 (width too large for virtual size) (II) I810(0): Not using built-in mode 1600x1200 (width too large for virtual size) (II) I810(0): Increasing the scanline pitch to allow tiling mode (1280 - 2048). (--) I810(0): Virtual size is 1280x1024 (pitch 2048) (**) I810(0): *Built-in mode 1280x1024 (**) I810(0): *Built-in mode 1024x768 (**) I810(0): Built-in mode 800x600 (**) I810(0): Built-in mode 640x480 (II) I810(0): Attempting to use 75.02Hz refresh for mode 1280x1024 (849) (II) I810(0): Attempting to use 75.08Hz refresh for mode 1024x768 (845) (II) I810(0): Attempting to use 75.00Hz refresh for mode 800x600 (843) (II) I810(0): Attempting to use 75.00Hz refresh for mode 640x480 (841) (++) I810(0): DPI set to (100, 100) Машины этой под рукой нет, но есть с собой конфиг и лог. Помогите, кто чем может.
Re: OpenVZ, VServer и пол удесяток
On 25-Dec-2007, Alexey Pechnikov wrote: Не совсем понял, как это объясняет жуткое скрежетание винтом от команды rm? Мало того, что тормозит, еще и винт мордует. Притом так, что я уже не рискую подобные тесты запускать, не хочется винт угробить. Рекомендую запустить действительно тесты, а вообще сделать бэкап важных данных.. Винты любят дохнуть очень произвольно. И причина этого не в rm. А не проще ли примонтировать что-нить напр. tmpfs куда надо? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openvz, vserver
Konstantin Matyukhin пишет: Алексей, посмотри на виртуализацию с другой стороны -- не всегда твоя задача сможет загрузить имеющееся в твоём распоряжении железо, а если она использует его менее чем на 10%, то, возможно,сам задумаешься - чем бы его нагрузить, а может - начальство за тебя подумает ;-) Тут хочешь-не хочешь - вспомнишь и про виртуализацию.Особенно, если придётся делить ресурсы сервера с кем то ещё. Сразу предвижу возражение: зачем под задачу, которая требует 486 процессор покупать Коре Дуо? этой осенью мы были вынуждены купить железки на 1.5ГГц Целеронах, хотя заказывали с 566МГц процессорами (их нам тоже за глаза). С другой стороны - цена процессорной мощи того же коре дуо может быть много меньше цены одного юнита в стойке. Пора завязывать толочь воду в ступе-то. завязываю, просто люди очевидных вещей не понимают(ИМХО) -- С уважением, Любимец Андрей Алексеевич -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openvz, vserver
Если возрастает незначительно, согласен. Но пока что я конкретных цифр не видел, может, плохо искал. Мои соображения следующие: раз дублируются все системные вещи (не знаю, как грамотно сказать), то нагрузка от каждого виртуального окружения по порядку величины равна нагрузке от основной системы. Возможно, для вас это мелочь и четыре-восемь процессорных ядер на сервере вместо одного-двух есть разумная плата за удобство. Вот статейка есть на тему производительности: http://www.hpl.hp.com/techreports/2007/HPL-2007-59.pdf Вот спасибо - именно то, что надо! С xen и openvz вопрос решен.
Re: openvz, vserver
On 25-Dec-2007, Alexey Pechnikov wrote: Мои соображения следующие: раз дублируются все системные вещи (не знаю, как грамотно сказать), то нагрузка от каждого виртуального окружения по порядку величины равна нагрузке от основной системы. Твои соображения демонстрируют лишь непонимаение базовых концепций, не желании их узнать(хотя бы, открыв википедию). Не желание их знать - законное право, зачем это демонстрировать? не их желании знать Возможно, для вас это мелочь и четыре-восемь процессорных ядер на сервере вместо одного-двух есть разумная плата за удобство. * Virtual servers share the same system call interface and do not * have any emulation overhead. * Virtual servers do not have to be backed by opaque disk * images, but can share a common file system and common sets of * files (through copy-on-write hard links). This makes it easier * to back-up a system and to pool disk space amongst virtual * servers. * Processes within the virtual server run as regular * processes on the host system. This is somewhat more * memory-efficient and I/O-efficient than whole-system * emulation, which cannot return unused memory or share a * disk cache with the host and other virtual servers. * Processes within the virtual server are queued on the * same scheduler as on the host, allowing guests * processes to run concurrently on SMP systems. This is * not trivial to implement with whole-system emulation. * Networking is based on isolation rather than * virtualization, so there is no additional overhead * for packets. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: L192WS widescreen
2007/12/25, DrMoriarty [EMAIL PROTECTED]: Превед всем. У меня возникла проблема, собрал другу компьютер с сабжевым монитором, поставил на него Etch 4.0 без обновлений. Монитор отказался включаться в режиме 1440х900. В интернете прочитал, что широкоформатные мониторы лечат обычно вставкой соответствующего Modeline. В xorg.conf внёс такие изменения Section Monitor ... UseModesMyModes0 EndSection Section Modes IdentifierMyModes0 Modeline 1440x900 106.50 1440 1488 1536 1840 900 902 905 947 -HSync +Vsync EndSection ... Section Screen ... SubSection Display Viewport 0 0 Depth 24 Modes1440x900 1280x1024 1024x768 EndSubSection Включать нужный видео режим монитор всё равно отказался, аргументируя это следующей выдержкой из Xorg.0.log (II) I810(0): Monitor0: Using hsync range of 30.00-83.00 kHz (II) I810(0): Monitor0: Using vrefresh range of 56.00-75.00 Hz (II) I810(0): Not using mode 1440x900 (no mode of this name) (II) I810(0): Not using built-in mode 1920x1440 (width too large for virtual size) (II) I810(0): Not using built-in mode 1600x1200 (width too large for virtual size) (II) I810(0): Increasing the scanline pitch to allow tiling mode (1280 - 2048). (--) I810(0): Virtual size is 1280x1024 (pitch 2048) (**) I810(0): *Built-in mode 1280x1024 (**) I810(0): *Built-in mode 1024x768 (**) I810(0): Built-in mode 800x600 (**) I810(0): Built-in mode 640x480 (II) I810(0): Attempting to use 75.02Hz refresh for mode 1280x1024 (849) (II) I810(0): Attempting to use 75.08Hz refresh for mode 1024x768 (845) (II) I810(0): Attempting to use 75.00Hz refresh for mode 800x600 (843) (II) I810(0): Attempting to use 75.00Hz refresh for mode 640x480 (841) (++) I810(0): DPI set to (100, 100) Машины этой под рукой нет, но есть с собой конфиг и лог. Помогите, кто чем может. Видеокарточка интеловская. У меня (на 945 чипсете) вылечилось установкой пакета 915resolution. В логах была такая же ругань. -- WBR, Max Vasin JID: [EMAIL PROTECTED]
Re: OpenVZ, VServer и полудесяток
В сообщении от Tuesday 25 December 2007 06:51:57 ph написал(а): On 25-Dec-2007, Alexey Pechnikov wrote: Тогда по идее rm -rf /test/test_1/ должно работать быстро, поскольку список файлов не передается Здесь-то что мешает? Надо пройти по всем файлам рекурсивно, сделать unlink, если какой-то процесс держит файл открытым, удаление будет откладываться, как и удаление каталогов к которых он находится. что наверняка и проиходит. обходных путей несколько, в разной степени корретных, но я сомневаюсь, что тикл их использует. Разве что если эти файлы от как сам и держит:) При тестировании запускал один скрипт, который и обращался к файлам. Больше никто их не трогал. Проверил на двух разных машинах, поскольку удивился полученному эффекту. Никакие обходные пути не нужны, раз доступ однопользовательский.
Re: L192WS widescreen
Спасибо, попробую. 25.12.07, Max Vasin [EMAIL PROTECTED] написал(а): Видеокарточка интеловская. У меня (на 945 чипсете) вылечилось установкой пакета 915resolution. В логах была такая же ругань. -- WBR, Max Vasin JID: [EMAIL PROTECTED]
Re: openvz, vserver
Alexey Pechnikov wrote: В сообщении от Monday 24 December 2007 21:01:11 Alex Kuklin написал(а): Alexey Pechnikov wrote: Я полагаю, что ваше суждение мало связано с реальной жизнью, а применимо лишь к некоторому сферическому серверу в вакууме. И предлагаю вернуться к разговору о том, как, зачем и почему можно|нужно использовать виртуализацию после обретения вами практического опыта работы с реальными серверами. Пока я не увидел, ради чего использовать виртуализацию на своих серверах. Вы упомянули про ограничение ресурсов (про разграничение прав доступа не будем, это уж кому как нравится реализовывать) - для ограничения ресурсов одного приложения создавать виртуальную машину мне кажется неоправданным. Если я не путаю, в солярисе для этих надобностей есть так называемые контейнеры, и вроде даже их начинали портировать под линукс. Если вы потрудитесь изучить вопрос, прежде чем рассуждать, то вы увидите, что OpenVZ как раз и реализует модель паравиртуализации, при которой расходы на создание каждого нового VE мизерны. Это не создание полной виртуальной машины со своим процессором, памятью и железом, а разграничение на уровне (грубо говоря) вызовов ядра. Во сколько раз возрастает количество вызовов при названном подходе? Each VPS performs and executes exactly like a stand-alone server; VPSs can be rebooted independently and have root access, users, IP addresses, memory, processes, files, applications, system libraries and configuration files. Если возрастает незначительно, согласен. Не значительно. Вышеописанный оверхед заключается в начальном запуске системы. Если систему (VE) не перегружать по 10 раз на дню, то его и нет. С точки зрения процессов оверхед такой мизерный, что возможно одновременное исполнение сотен VE с апачем, раздающим статику, в каждом, на вполне обычной машине. Но пока что я конкретных цифр не видел, может, плохо искал. Плохо искали. Для openvz есть подробный анализ Мои соображения следующие: раз дублируются все системные вещи (не знаю, как грамотно сказать), то нагрузка от каждого виртуального окружения по порядку величины равна нагрузке от основной системы. Там НЕ дублируются системные вещи. Понимаете, НЕ дублируются. Возможно, для вас это мелочь и четыре-восемь процессорных ядер на сервере вместо одного-двух есть разумная плата за удобство. Доктор, а как у меня openvz крутилось на машинке p3-1333/512 памяти? Я что-то делал не так? -- Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openvz, vserver
On Tue, Dec 25, 2007 at 03:17:42AM +0300, Alexey Pechnikov wrote: Пока я не увидел, ради чего использовать виртуализацию на своих серверах. Вы упомянули про ограничение ресурсов (про разграничение прав доступа не будем, это уж кому как нравится реализовывать) - для ограничения ресурсов одного приложения создавать виртуальную машину мне кажется неоправданным. Если я не путаю, в солярисе для этих надобностей есть так называемые контейнеры, и вроде даже их начинали портировать под линукс. Если вы потрудитесь изучить вопрос, прежде чем рассуждать, то вы увидите, что OpenVZ как раз и реализует модель паравиртуализации, при которой расходы на создание каждого нового VE мизерны. Это не создание полной виртуальной машины со своим процессором, памятью и железом, а разграничение на уровне (грубо говоря) вызовов ядра. Во сколько раз возрастает количество вызовов при названном подходе? Each VPS performs and executes exactly like a stand-alone server; VPSs can be rebooted independently and have root access, users, IP addresses, memory, processes, files, applications, system libraries and configuration files. Это еще от технологии виртуализации зависит. Если взять тот же XEN, то там происходит именно эмуляция виртуального железа, плюс патченое ядро, которое умеет работать с этим XEN-овским железом. В таком случае все что написано выше -- верно. Даже shared memory не шарится между виртаулками. А вот тот-же vserver больше похож на чрут + N-ое количество костылей для разделения ресурсов. Грубо говоря для того, чтобы внутри виртуалки была своя нумерация процессов (т.е чтобы у init'а был PID=1 и чужиме процессы не были видны). Ну и аналогично для сети, файловой системы. Сильно большого оверхеда во втором случае не будет. -- WBR, Dmitry signature.asc Description: Digital signature
