Не буду говорить про Solaris на Санках - не видел - но на писюках 8(((

Раз уж тут собрались крутые солярщики - повторю вопрос в который раз:

Есть машины 2хКсеоны. На них Соляра 9 (решение НЕ мое). Так вот, эта штука периодически (раз в день-три) виснет следующим образом:
По ssh зайти иногда можно, иногда нет. Чаще - можно.
Работа в консоли с такой скоростью, как со Штатами и небыстрому каналу
Апач висит, слушает, клиентам ничего не отдает. Вообще.
Рестарт апача ничего не дает.

Лечится это только reboot'ом.

И что с этим счастьем делать? 8(

2Lem_I
>МИКРОЯДРО ядро я слабали классную операционку, которая, я уверен, скоро появится в версии для PC от Apple.

x86 и чистое микроядро вещи малосовместимые (ImHO) ... сколько уже это обсасывалось а всё туда же ;)

Respect!!!

--> Zulu

Vseo eto lecitsea uvolneniem sysadmina!

>Vseo eto lecitsea uvolneniem sysadmina!

>anonymous (*) (2003-09-23 13:06:31.726314)

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

Здравствуйте Уважаемые! :)

Можно мне тоже кое-что вставить про солярку? Пользовал я несколько лет (этак годка 4) УльтраСпарки 5 и 10. И пользовал их как рабочие станции для CAD-системы. Вот мои впечатления :) 1. Исчерпывающая документация 2. Устойчивая работа системы даже в случае использования совместно с тупым юзером (первый раз сел за компьютер) 3. Обновления рассылаются постоянно на CD (только заплати за техподдержку) 4. Техподдержка работает хорошо 5. Непонятно почему, но требования к железу моей CAD системы для солнечной солярки в разы отличались от HP, IRIX и прочих униксов. Пример: - память: солярка - 128 Мбайт (лучше 256), НР - 768 Мбайт, IRIX - 1 Гбайт - HDD: солярка - 4 Гбайт, НР - 20 Гбайт, IRIX - 20 Гбайт Я не большой спец в различиях разных операционок и железа, но почему это так? Система заточена не под солярку. 6. Быстродействие системы. Проводили сравнительные тесты быстродействия систем на рендеринге картинок с помощью программы povray (надеюсь слышали про такую :)) УльтраСпарк 10 - проц 230 Мгерц, 256 Мбайт памяти, свап - 512 Мбайт. Интел+Винда - 512 Мбайт памяти, проц непомню какой, но на тот момент (2000 год) самый крутой, свап - стандартный виндовый. Выигрыш - спарк (а он к тому времени был уже далеко не новый) драл навороченый винтел в 4 раза, при условии что он работал паралельно как удаленный сервер. То есть на нем работал 1 пользователь удаленным х-терминалом, т.е. работал с CAD-системой. 6. Легкость установки как самой системы с нуля, так и установка патчей и других программ. К моменту начала работы с Ультраспарками я не имел опыта работы с юниксами вообще. Вывод, классное железо и классная операционка - рабочая лошадка одним словом. Но это мое мнение. За чужой неудачный опыт я не отвечаю и тем более не несу ответственности :))) На настоящий момент я нашел только одну удовлетворяющую меня по устойчивости и документированию операционную систему - FreeBSD 4.7 - ТОЛЬКО НЕ НАДО КИДАТЬ В МЕНЯ КАМНИ. Если хотите убедить меня в дерьмовости солнечной солярки, то объясните мне все по пунктам. Может и поверю :))

Меня тоже, пожалуйста, убедите в дерьмовости Солнцедара.
Юзали x86 Solaris 8 на Compaq Proliant 350 1x1GHz P4,
530G2 2x2.4 Xeon, NCR S26, самосборке. Сейчас крутятся Informix 9.20, Oracle 8.1.7, апачи, томкаты, самбы всякие - простои были только из-за железа. По моим наблюдениям (с 1995г) - устойчивей работает только
классика, старичок SparcServer 1000.

P.S. Хорошо собранные писюки со Слакой (3.5 - 9.0) тоже
не подводили

BYE

Slacker

Уважаемый анонимус 13:29:38. А вы IBM MQSeries на соляру не ставили? А ведь требует перезапуска машины после изменения параметров в конфигурационном файле (проверьте - в документации описано). Нехорошо, вот Linux перезагружать не надо.

Скажите пожалуйста, куда делись супер-пупер рабочие станции Sun. Помню sunBlade 100 и такую красивую с подсветкой логотипа 1000. Последний рубеж обороны у санок остались только серверы?

> FreeBSD 4.7 - ТОЛЬКО НЕ НАДО КИДАТЬ В МЕНЯ КАМНИ

Я кину в Вас камешек. Где Sun J2SDK 1.4.2 и даже 1.4.1 для R.I.P.?

> Я кину в Вас камешек. Где Sun J2SDK 1.4.2 и даже 1.4.1 для R.I.P.?
> anonymous (*) (2003-09-23 13:53:10.840735)

Запрещена к распространению в бинарном виде по штатовским законам без отчисления неслабого бабла за сертификацию.

"Суслика видишь? А он ЕСТЬ!"

>Запрещена к распространению в бинарном виде по штатовским законам без отчисления неслабого бабла за сертификацию.

То есть нет 1.4.2 для *RIP?

Для anonymous (*) (2003-09-23 13:53:10.840735) :)))

> Скажите пожалуйста, куда делись супер-пупер рабочие станции Sun. :)) Батенька, а вы правы. Они куда-то делись. Законы рынка практически всегда нарушают одну народную мудрость - скупой платит дважды. Погоня за дешевизной в ущерб другим характеристикам товара ни к чему хорошему не приводит. Таже CAD-система у нас функционировала и на винтеловских рабочих станциях. Печальное зрелище... Извините, но когда из-за дисковых операций подвисает система, то это дерьмо а не операционка. (Ладно, опять старые песни о хреновых окнах - больше не буду). А вот то что диски летят каждые три-четыре месяца это уж точно виновата не операционка, а архитектура в целом. А ваш камень меня не достиг :)) Так как я работал с явой на солярке и не заметил проблем. Может у меня есть устройство /dev/hands помогающее в критических ситуациях? Это своего рода катапульта на самолете :))

Что касается FreeBSD, то я сейчас уже около 2 лет не работаю с солнечной соляркой (и даже не в той организации :))) и решаю далеко не те задачи про которые написал. Для теперешних задач все-таки лучше использовать Free (хотя я в свое время и проверял возможность использования солярки для нынешних задач). И считаю что FreeWare и Linux/Windows Ware в этой темке не стоит обсуждать :)) Для этого есть специальные форумы для флуда :-P

Простите, а у Вас SCSI (Fast-, UW-, etc.- навороты) или IDE диски? Не пробовали ли Вы новую Serial ATA?

SCSI, SCSI и на спарках и на винтеле. Диски от одного производителя :)) А частые дисковые операции из-за хреновой работы окошек с большими объемами данных в ОЗУ. Постоянно свопингует. Хотя памяти должно хватать выше крыши. (повторю - на спарке 128 и 256 Мбайт ОЗУ, на винтеле 512 Мбайт).

Не знаком с Вашей задачей. На Java (!:)) сервере приложений у нас Intel архитектура забила SunBlade (100 и 1000).

Понимаю, что сановские маркетоиды скажут "покупайте Sun _сервер_ для сервера приложений", но я больше склонен к Itanium II и Linux+IBMJ2SDK - просто быстрее, "365x7x24" и дешевле.

Ну у меня была задача поддержки работоспособности CAD-системы. :)) Там явы не было. На яве я решал другие задачи и работоспособность на спарке и винтеле не сравнивал. А сравнивал я чисто на расчетной программе povray. Поясню если не знаете, что такое. POVRAY - программа рендеринга фотореалистичного изображения по текстовому описанию. Оговорюсь сразу, вывод изображения мы отключили, скидывали в файл. И офисные приложения мне понравились на спраке. Есть там такой пакетик - звездный офис :)) Классная альтернатива для оконного офиса :)) (Блин опять софт равнять стал - извините не хотел).

> Есть там такой пакетик - звездный офис :)) Классная альтернатива для оконного офиса :))

Вообще-то Open Office входит в современные Linux дистрибутивы...

>Captain Nemo.
>Асинхронный ввод-вывод в Linux-е давно был.

Давно это когда?
Со времен RHAS?
Ну очень давно :)
Ораклу понадобилась асинхронность(и вообще нормальный ввод-вывод), вот и довели до ума ядро(теперь уже общедоступное).

Moving Linux into the Enterprise(т.е. просто так линукс не готов
к юзанию на уровне предприятия, его надо было "Moving" :) ):

http://otn.oracle.com/oramag/oracle/03-jul/o43linux.html

Take the case of I/O throughput—a critical component for a high-performance database. "We know that we need to be able to have a single call launch thousands of I/Os," says Enright. "We know that we need to have those I/Os complete in a timely fashion, and that if we have to wait for them to complete in sequence we'll have less throughput." However, when the Linux kernel team at Oracle initially started to explore the performance and scalability of Linux as an

enterprise platform, it quickly found problems.
^^^^^^^^^^^^^^^^^^
Только упертые не видят проблем. Спецы их узрели quickly.

Asynchronous I/O—a key capability required to move large amounts of data to multiple disks—did not deliver well.

Digging deeper, the team found that in the existing Linux kernel there
was only a single lock for SCSI on a system. "It didn't matter if you
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
had a half dozen controllers or one controller—there was a single lock," says Enright. "As you added hardware to increase performance you were still sharing a single lock, so there was really no noticeable improvement."

Т.е. еще совсем недавно линукс(его хваленое красноглазыми ядро) был абсолютно непригоден к серьезным нагрузкам по I/O.
А быстро у нас что родится?

То немногое, чего нет в Linux дистрибутивах (GPL)

1. Системы гарантированной асинхронной доставки очередей сообщений (лечится скачиванием Sun J2EE, если ломает покупать IBMMQS)

2. Не-CORBA системы обработки транзакций (типа IBMCICS).

3. Сетевые СУБД (Raima aka Birdstep совсем охамела c триал-версией - см. их сайт)

Остальное всё в Linux есть и всё почти по GPL.

>Давно это когда?
>Со времен RHAS?
>Ну очень давно :)

С момента появления glibc.

head -n1 /usr/include/aio.h
/* Copyright (C) 1996, 1997, 1998, 1999, 2000 Free Software Foundation,
Inc.

Я веть кажется намекнул, что речь идет о KAIO - и веть не спорил.
Posix AIO в Linux-е есть давно. KAIO - как возможная реализация
AIO отсутствовала. (для особо одаренных - KAIO это kernel level AIO)


> Спецы их узрели quickly.
Я не упертый и проблемы Linux-а более или менее знаю. Только все
познается в сравнении. Да и не Linux-ист я. Приходится работать и с
Solaris и с Windows и с Linux. Везде свои плюсы и минусы.

>Спецы их узрели quickly.
Это Вы про себя? Малацца аднака!

>Т.е. еще совсем недавно линукс(его хваленое красноглазыми ядро) был
>абсолютно непригоден к серьезным нагрузкам по I/O.

Так веть недавно это дядя для каждого по разному. Для иных недавно
и Solaris-а и Windows-а да и Unix-а и в помине то небыло! А для других
и война недавно была ...

Kernel summit в котором Oracle поднимал эти проблемы был помоему года
2 назад или более.
Так что если сегодня поглядеть, то веть правы оказались 'красноглазые'
то. ( не в пример синеглазкам )

Captain Nemo

to Captain Nemo
А чё за "веть" такая?

Mimino;

>А чё за "веть" такая?

Класс! Сработало! Я на эту 'веть' две бутылки пива имею! Мы тут сидим с приятелями квасим пиво. Я написал первый раз 'веть', и полез исправлять, а друзья об заклад бьются - оставь говорят все равно не заметят, даже если ты штук пять этих 'веть'-ей наляпаеш. Ну и проспорили по бутылке ...

А вот что за 'че' такая ?

Приятно повеселиться !

Captain

SunBlade

2 Anonymous (*) (2003-09-23 14:33:18.011191)

А теперь идём вот сюда:
http://www.sun.com/desktop/products/ws.html

и наконец втыкаем, что меряться серверной производительностью между Intel-сервером и entry-level WORKSTATION sb100, с одним старым камнем, материнкой, имеющий левый чипсет и понимающей Intel-камни, а также WORKSTATION sb1000 с одной-единой головой, по меньшей мере, неумно.

руки лечите

2 Zulu (*) (2003-09-23 12:21:00.11889)

1) долго и печально втыкать в HCL на предмет, совместимо ли имеющееся железо с Solaris
2) накатить последний 9_Recommended
3) man ndd (это, кстати, и тем дятлам, которые тут звездели про невозможность "тонкого тюнинга" Solaris. То, что вы не знаете, как это делается, еще не означает, что Solaris этого не умеет.)

P.S. готов за $1000 в какие-то три дни сделать вам полное щастье с вашим Solaris 9.

RSBAC (Linux) vs RBAC (Solaris)

2 anonymous (*) (2003-09-23 10:27:45.513084):

>>c) проблемы с софтом: большинство программ проверяют не
>>наличие какой-либо capability, а euid == 0.

> Проблемы надуманы.

Ничего подобного. Вот хочет эта зараза сделать setuid(0), и все тут,
хоть тресни!
Поэтому ситуация с RSBAC весьма комична: сначала пишем модуль
AUTH, а потом ставим почти всем демонам AUTH_CAPABILITY 0,
хотя оно им НЕ НАДО -- все права у них есть благодаря rc_force_role и
правильно поставленным ACL, да и сам по себе факт [e]uid == 0 ничего не
значит.


> Как уже сдесь заметили это решается элементарно.
> Я ( посмотрев в архиве списка рассылки ) не видел ни одной проблемы,
> которую не удалось бы разрешить.

То, как это делается -- шаманство. Правильный способ состоит в том,
что софт должен правильно работать с RSBAC, т.е. (как тут уже писали)

./configure --enable-rsbac=yes --blah-blah

А это потребует большого количества усилий...

> RSBAC - очень богатая и продвинутая штука.

Да. Но почти никакой софт не использует эту функциональность... :((

>>b) RSBAC + backup == геморой немеряный
> Это слишком сильное утверждение.

http://www.rsbac.org/instadm.htm#backup

И Вы скажете, что это не геморой? Особенно если пользоваться PM...


> По крайней мере mv, cp ... элементарно автоматизировать.

Да, еще dpkg, apt-get, vim,...., да все, одним словом...


> А Вы не копайтесь. Ведь Вы не собираете ядро соляры из исходников.
> Берите дистрибутив в котором это УЖЕ есть.

Какой такой?

Adamantix? -- там RSBAC рекомендуют только шибко продвинутым, да и
проблемы с софтом -- те же.
ALT Linux Castle? -- они на него сами забили, похоже...
Kaladix -- ну нафиг, с их source-based религией...

> Ведь Вы не собираете ядро соляры из исходников.

Нет надобности.

про microkernel и x86

2 sS:

> x86 и чистое микроядро вещи малосовместимые (ImHO)

Это высказывание -- обычный microkernel FUD.

Просто microkernel должно быть micro во всех смыслах
-- никаких драйверов, планировщиков и т.п. в ядре!

Только работа с MMU, прерываниями ( в стиле
"по прерыванию X разбудить поток Y) и _простейшее_ IPC.

Тогда и context switch не будет ужасно болезненным.

http://www.l4ka.org/projects/pistachio/

...

2Dselect
>Это высказывание -- обычный microkernel FUD.

Разумеется ;)

>Просто microkernel должно быть micro во всех смыслах
>-- никаких драйверов, планировщиков и т.п. в ядре!

>Только работа с MMU, прерываниями ( в стиле
>"по прерыванию X разбудить поток Y)

это уже context switch ;)

>и _простейшее_ IPC.

>Тогда и context switch не будет ужасно болезненным.

>http://www.l4ka.org/projects/pistachio/

Это все красиво на бумаге - как в реальной жизни будет ХЗ (ImHO)

ibm mqseries глюкало ещё то.

$330 в день ... Если начнут платить такие деньги, причём постоянно, то, пожалуй, стоит уйти на вольные хлеба ;)

1) Абсолютно. Более того, эта проблема на двух(!) из пяти(!) одинаковых серверов.
2) ...
3) ЩАС...

давайте не путать божий дар с яичницей

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

Так что пусть салезы нас продают, а бухгалтерия платит зарплату. "У меня с банком договор: я не даю взаймы, они не торгуют семечками".

P.S. JFYI - в среднем час работы квалифицированного IT-консалтера стоит от $200.

хехе

То есть, "шах расписался в полном неуменьи".

Сами мы сделать не можем, нанять специалиста, который сможет, не желаем. Так и будем делать регулярный reboot одного из самых стабильных коммерческих UNIX-ов. By crooked hands reasons.

А если вы таки думаете, что кто-то бесплатно вам тут будет давать уроки по настройке Solaris, то надежды юношей питают.

> Это все красиво на бумаге - как в реальной жизни будет ХЗ (ImHO)

Вообще-то в реальной жизни давным-давно существует QNX. Вполне прилично работал еще на 386.

...

2lukin
>Вообще-то в реальной жизни давным-давно существует QNX. Вполне прилично работал еще на 386.

А какое отношение имеет QNX к заботливо отрезанной Вами ссылке ?

http://www.l4ka.org/

Совершенно верно. Не могу.

И, более того, не считаю, что должен уметь решать такую проблему. Я считаю, что такой проблемы не должно существовать в принципе.

И, кстати, юношей питают НАУКИ. Учите классиков.

Вот только что - убийственный случай.

Апач не стартует. молча. В логах - ничего.

Ну что тут сделать? делаем
# truss -o apache httpd
и с офигеванием видим, что
open("/var/www/logs/access_log", O_WRONLY|O_APPEND|O_CREAT, 0644) ВЫВАЛИВАЕТСЯ С E_OVERFLOW!!!

Супер!

...и виноват в этом конечно солярис?

про microkernel и x86. часть 2

> Это все красиво на бумаге - как в реальной жизни будет ХЗ (ImHO)

Это не на бумаге, это -- медицинский факт.

http://os.inf.tu-dresden.de/L4/LinuxOnL4/

Нужна только _нормальная_ userspace часть
(L4Hurd? http://mail.gnu.org/mailman/listinfo/l4-hurd )

>>Вообще-то в реальной жизни давным-давно существует QNX. Вполне прилично работал еще на 386.

>А какое отношение имеет QNX к заботливо отрезанной Вами ссылке ?

>http://www.l4ka.org/

Он имеет отношение не к этой ссылке, а к смелому заявлению раньше:

>> x86 и чистое микроядро вещи малосовместимые (ImHO) ... сколько уже это обсасывалось а всё туда же ;)

Стильно ;)

2lukin >Он имеет отношение не к этой ссылке, а к смелому заявлению раньше: Дык это не мое "смелое заявление" а как правильно заметил уважаемые Dselect miсrokernel FUD, если вам его надо - идите почитайте архив lkml на эту тему а чего тут то нам бегать по кругу в 333 раз.

miсrokernel

>Dselect miсrokernel FUD, если вам его надо - идите почитайте архив lkml
>на эту тему а чего тут то нам бегать по кругу в 333 раз.

Ткните урлом, - что за архив lkml?
Действительно не понятно чем интел(особенно последние процы,itanium,
P4C с гипертредингом) не угодил микрокернелу?
И чем тормозные процы санов и Hp лучше в этом плане?