[image]

Новый сервер Авиабазы

 
1 2 3 4 5 6 7

hcube

старожил
★★
75 Gb IBM Deskstar 75GXP (DTLA-307075) 100

Неужели вдвое больше места не стоят дополнительных $25?
   
+
-
edit
 

=KRoN=
Balancer

администратор
★★★★★
hcube>Неужели вдвое больше места не стоят дополнительных $25?

Стоят. Просто это ещё только прикидка. Всё равно всех денег ещё не собрали. На руках только ~$1600.
   

hcube

старожил
★★
Неее... раз деньги есть - лучше мощную машинку. На крайняк - пока не ставить половину памяти и резервный IDEшник (кстати его я бы брал объемом поболее - 120, лучше всего).
   

KeyOS

новичок
Свои пять копеек.

1. Два процессора на такой тип работы - трата денег. Основная работа у www машин это I/O (какие бы хитрые вычисления наш ЮББ не делал ;) )
2. На "нормальных" серверах предпочтительнее RAID 0+1 или RAID 5. В первом случае надо два диска, во втором три. Делается во избежание проблем с восстановлением после физицких смертей дисков которые как ни странно, но всё ещё случаются.
3. На мой взгляд оптимальная конфигурация это:
P-III > 850 Mhz
1+ Gb RAM
2x18 (or 2x36) SCSI disks
RAID controller (Adaptec rulez ;) ) (or software raid + regular SCSI controller Adaptec 29xx)
На всё остальное (типа чья доска или какая память я бы не смотрел, а брал бы дешевле.)
Нормальные бэкапы делаются на кассеты. DLT самое, что ни на есть то, но стоит очень немало. С другой стороны у нас есть кассеты 5-ти летней давности которые без проблем читаются. DAT через год-два можно только на пальцы наматывать.

2 варбан: видел, что вы против RAID, но причин не понял. У меня есть примерно 150 серверов которые после одного случая в срочном порядке добивал до Mirror. Насчет производительности это как раз наоборот только увеличение наблюдается, потому как чтение убыстряется.

2 hcube: Fujitsu выпускают в последние годы одни из самых качественных дисков. На мою память полетело пара-тройка IBM дисков, пара Seagate и ни одного Fujitsu. Парк компьютеров о которых идет речь примерно 350-400 машин.
   
+
-
edit
 

=KRoN=
Balancer

администратор
★★★★★
KeyOS>1. Два процессора на такой тип работы - трата денег. Основная работа у www машин это I/O (какие бы хитрые вычисления наш ЮББ не делал ;) )

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


В случае же UBB в моей обработке всё ещё хуже. Сейчас многие фичи отключены, ещё больше - не реализованы. Достаточно сказать, что реализация полноценных, а не кастрированных автоссылок требует секунд до 30 на обработку 30-килобайтной страницы на PIII-450МГц.

А я ещё хочу и с графикой на лету работать...

KeyOS>2. На "нормальных" серверах предпочтительнее RAID 0+1 или RAID 5. В первом случае надо два диска,

А на четыре? Два - это либо RAID-0, либо RAID-1, но не 0+1.

KeyOS>во втором три.

От трёх и более.

KeyOS>3. На мой взгляд оптимальная конфигурация это:
KeyOS>P-III > 850 Mhz
KeyOS>1+ Gb RAM
KeyOS>2x18 (or 2x36) SCSI disks
KeyOS>RAID controller (Adaptec rulez ;) ) (or software raid + regular SCSI controller Adaptec 29xx)

Почти такая система (только что памяти 512 и винты IDE) стоит сейчас у Юки. Одна Авиабаза в "полном оснащении" уже в эти рамки не влезает. А мы хотим к себе ещё кучу проектов затаскивать...

KeyOS>На всё остальное (типа чья доска или какая память я бы не смотрел, а брал бы дешевле.)

Э... Ну, слов нет :D Разница в скорости под вышеперечисленное добро в разных системах может быть в разы.

KeyOS>Нормальные бэкапы делаются на кассеты. DLT самое, что ни на есть то, но стоит очень немало. С другой стороны у нас есть кассеты 5-ти летней давности которые без проблем читаются. DAT через год-два можно только на пальцы наматывать.

Кто кассеты будет менять? Туда доступ по спецпропуску, выписываемому за сутки. И ехать надо куда-то.

KeyOS>2 варбан: видел, что вы против RAID, но причин не понял. У меня есть примерно 150 серверов которые после одного случая в срочном порядке добивал до Mirror. Насчет производительности это как раз наоборот только увеличение наблюдается, потому как чтение убыстряется.

По деньгам обычно не окупается. Сверхнадёжность нам не нужна, если будет даже суточный откат (при ежедневных бэкапах) это не так страшно.
   
+
-
edit
 

=KRoN=
Balancer

администратор
★★★★★
По поводу машины Олега Лазутченко - вчера сошлись на том, что хорошо бы её продать процентов за 70 от номинальной стоимости и добавить эти деньги к авиабазным. Тогда б можно было совсем что-то хорошее собрать :)
   
+
-
edit
 

=KRoN=
Balancer

администратор
★★★★★
Год назад он был взят за две с лишним тысячи уездных енотов.
   

KeyOS

новичок
=KRoN=>Форумы, даже классические, довольно сильно грузят процессоры. На той же конфигурации двухпроцессорная система оказывается в полтора раза быстрее однопроцессорной -

Насколько я помню (хотя давно это было) ЮББ написан на перле и пользует текстовые файлы. Да и вообще где тут multiprocessing/multithreading ?
Форумы насколько я понимаю работают как обычный CGI скрипт которому многопроцессорные системы до фени. Собссно улучшение производительности вы получаете за счёт свободного времени второго CPU, что на мой взгляд не совсем целесообразно с точки зрения расхода денег.
Конечно если очень хочется, то можно ;) Но с таким подходом можно спокойно 16xUltraSparcIII 900Mhz загрузить теми же форумами :D

=KRoN=>В случае же UBB в моей обработке всё ещё хуже. Сейчас многие фичи отключены, ещё больше - не реализованы. Достаточно сказать, что реализация полноценных, а не кастрированных автоссылок требует секунд до 30 на обработку 30-килобайтной страницы на PIII-450МГц.

А вы какой нибудь профайлинг делали, чтобы установить, что процессор виноват ?

=KRoN=>А я ещё хочу и с графикой на лету работать...

То есть ? В фотошопе фотки рендерить ?

=KRoN=>А на четыре? Два - это либо RAID-0, либо RAID-1, но не 0+1.

Сорри, пропустил "по".

=KRoN=>Почти такая система (только что памяти 512 и винты IDE) стоит сейчас у Юки. Одна Авиабаза в "полном оснащении" уже в эти рамки не влезает. А мы хотим к себе ещё кучу проектов затаскивать...

А я именно об этом и говорю, что основная работа это память и диски.

=KRoN=>Э... Ну, слов нет :D Разница в скорости под вышеперечисленное добро в разных системах может быть в разы.

Не понял. Я имел ввиду не тип памяти (т.е. ДДР с СДРАМ не собирался сравнивать) или чипсет, а производителей, потому как расброс цен (у нас во всяком случае) довольно большой.

=KRoN=>Кто кассеты будет менять? Туда доступ по спецпропуску, выписываемому за сутки. И ехать надо куда-то.

Ну я просто не совсем в курсе, что у вас делают, а, что нет. Просто делюсь опытом.
   
+
-
edit
 

=KRoN=
Balancer

администратор
★★★★★
KeyOS>Насколько я помню (хотя давно это было) ЮББ написан на перле и пользует текстовые файлы. Да и вообще где тут multiprocessing/multithreading?

В unix-системах многопоточность, как правило, не используется, только многопроцессность. Что же до UBB - сколько одновременно на форумах пасётся людей, поисковых систем, роботов - столько, помноженное в несколько раз (Apache + Perl + PHP + ... - на каждого свой экземпляр) работает процессов.

KeyOS>Форумы насколько я понимаю работают как обычный CGI скрипт которому многопроцессорные системы до фени.

Ты упускаешь, что CGI-процессов в системе может быть много. Кроме того, внутри одного CGI-запроса может тоже быть много процессов.

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

Загрузить можно хоть 20 процессоров, только средняя загрузка их будет невелика :)

Скажем, сейчас, когда Авиабаза практически простаивает, на ней постоянно активны 3..6 процессов, ещё 55 в спячке, загрузка процессора 1..2% (напомню, что 15% загрузка для сервера уже критична).

KeyOS>Конечно если очень хочется, то можно ;) Но с таким подходом можно спокойно 16xUltraSparcIII 900Mhz загрузить теми же форумами :D

А вот дисковая система у нас как раз не очень критична. Главное, что при редких случаях её интенсивной загрузки (при пересканированиях/переиндексированиях баз и т.п.) загрузка процессора не превышала тех же 20%.

KeyOS>А вы какой нибудь профайлинг делали, чтобы установить, что процессор виноват ?

Обычный top, в принципе, много может сказать.

KeyOS>То есть ? В фотошопе фотки рендерить ?

Нет. Для этого есть ImageMagick - кстати, все местные иконки, превьюшки и т.п. генерятся им. А ещё следует помнить про такую штуку, как АвиаТОП - это ~100тыс показов баннера в день. Баннер, хоть и кешируется (что не есть хорошо, просто генерацию на каждый запрос система сейчас не тянет), но генерится на лету.

KeyOS>А я именно об этом и говорю, что основная работа это память и диски.

Память и процессор. Недавние падения сервера были из-за нехватки как памяти, так и вычислительной мощности. Хотя, как говорит админ, процессора не хватало в первую очередь из-за того, что дисковая подсистема - IDE.

KeyOS>Не понял. Я имел ввиду не тип памяти (т.е. ДДР с СДРАМ не собирался сравнивать) или чипсет, а производителей, потому как расброс цен (у нас во всяком случае) довольно большой.

А... Так Intel сейчас в среднем дешевле, чем SuperMicro или Tyan. А кроме них серверные матери, вроде, никто не делает. Не GigaByte же брать? :)

KeyOS>Ну я просто не совсем в курсе, что у вас делают, а, что нет. Просто делюсь опытом.

Обычно у нормальных провайдеров машинный зал закрытое и охраняемое помещение, доступ в которое надо отдельно заказывать.
   
+
-
edit
 

Mishka

модератор
★★★
KeyOS>Вот тут вы для меня америку открыли. Сам будучи програмером под эти самые unix системы такое заявление слышу впервые. Для начала могу сказать, что одно другому (много- поточность/процессность) не мешает. Любую многопроцессную задачу пожно выполнить как многопоточную. Дело в предпочтении и экономии тех самых ресурсов, которые экономятся чуть лучше в многопоточной архитектуре. А откуда у вас такие данные если не секрет ?

Во многих Юнихах POSIX multithreading появился не так давно. Да и OpenSource пользоваться multithreading начал пользоваться еще недавнее. Тот же Apache в версии 1.х существенно многопроцесный, а не многопотоковый. А вот Apache 2.х уже многопотоковый. Опять-таки, Линух поддерживал весь POSIX не с первого дня, хотя он здесь и впереди Фряхи.

KeyOS>Простите, но обычный top к сожалению ничего сказать не может. Это красивая программа показывающая вам состояние системы с минимальным шагом в одну секунду. Ею надо пользоваться для беглого просмотра, но профайлинг к сожалению не из той области.

Это точно.

KeyOS>Опять не понял, а зачем доступ. Неужели некому раз в день кассету поменять ?

Я так понимаю, что в России, это не входит в понятие поддержки хостинга.
   
+
-
edit
 

varban

администратор
★★★☆
KeyOS> 2 варбан: видел, что вы против RAID, но причин не понял.

1. KISS
2. Тепло

KeyOS> У меня есть примерно 150 серверов которые после одного случая в срочном порядке добивал до Mirror.

Нууу!
У меня эдак на пару порядков меньше :)

Но я собирал/консультировал сборку нескольких серверов, и конечно, интересуюсь их состоянием.
Кстати, единственный случай полной потери инфы был как раз на SCSI RAID 5 о трех винтах - там сыпанулись два из них... вернее, контроллер подумал, что они сыпанулись, винты как раз в полном порядке.

Совсем недавно это было (я писал), и придется выковыривать данных еще.

А, и еще такое наблюдение: почему-то у коллег летят винты, которые в RAID'ах. Убей, но не помню случая полетевшего одиночного SCSI винта.
Хотя одинчных SCSI у знакомых больше, чем в RAID'ах.

Поэтому я последнюю неделю на райды окрысился. Пройдет, не беспокойтесь ;)

KeyOS> Насчет производительности это как раз наоборот только увеличение наблюдается, потому как чтение убыстряется.

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

А, и еще - подходявый для данного RAID'a поток. К примеру, быстрый поток коротеньких файлов (существенно меньше кэша) - смерть для RAID5 (и 3). Он свою силу показывает на гиговых файлах. А для коротких файлов подходит лучше одиночные винты. Или многодисковые (4...5, если 6, то лучше 50 изобразить ;) ) RAID5.

А трёхдисковой RAID 5 на коротких файлах может быть медленнее одиночного винта!
   
+
-
edit
 

GrayCat

координатор

varban>А, и еще такое наблюдение: почему-то у коллег летят винты, которые в RAID'ах. Убей, но не помню случая полетевшего одиночного SCSI винта.
varban>Хотя одинчных SCSI у знакомых больше, чем в RAID'ах.

varban>Поэтому я последнюю неделю на райды окрысился. Пройдет, не беспокойтесь ;)

Один из факторов к этому - то, что RAID-овые диски ставятся во всякие корзины, салазки и прочие Mobile-Rack-и. А лишние 80 контактов никогда не добавляли надежности. А уж если их сляпал на соплях дядюшка Ляо в подвале своей бамбуковой хижины...

Тут, видимо, еще и психологический фактор наличествует. Ставя диски в массив, невольно начинаешь допускать некие "послабления", зная, что смерть одного харда не фатальна. Ну там, на вентиляторе сэкономишь, в питание разветвитель поставишь...

Наш сервер на фирме как-то пару недель проработал без одного из 3-х дисков в массиве. Сдох один из слотов корзины, контроллер тут же "перестроился" и продолжал работать. А взглянуть в лог или на консоль никто не удосужился.

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

avmich

координатор

В целом по последним репликам больше согласен с KeyOS, чем с Кроном. И про многонитевость-многопроцессность (Linux поддерживает и то, и другое, и Апач тоже), и про неважность конкретного производителя с точки зрения скорости (важен чипсет, выставленные задержки памяти, а не конкретный исполнитель), и, конечно, про то, что CGI скрипты гораздо медленнее, скажем, кода на встроенном API. Кроме того, SQL, мне кажется, уже для Базы разумнее файловой системы. А кроме того :) $2k+ уже выглядят как-то странно... и особенно, что при этом в них нет хотя бы одного (!) гигабайта памяти...

Не выкручивайте скорость винтами, они механические... Увеличивайте объём ОЗУ (на серверных платах разъёмов много) и частоту процессоров...

(Да, в скобках, как человек, работавший с 1998 до 2000 года в индустрии жёстких дисков - самые качественные лиски в 2000 году считались от IBM, затем - от Fujitsu)
   
+
-
edit
 

=KRoN=
Balancer

администратор
★★★★★
avmich>И про многонитевость-многопроцессность (Linux поддерживает и то, и другое, и Апач тоже)

Так а что толку-то? Вот если рискну перейти на Apache 2.x, да ещё сумею софт на mod_perl перевести - то реальная многопоточность появится. Хотя имеет ли смысл - потоки же на разные процессоры не раскидаешь? Или можно?

avmich>и, конечно, про то, что CGI скрипты гораздо медленнее, скажем, кода на встроенном API.

Естественно.

avmich>Кроме того, SQL, мне кажется, уже для Базы разумнее файловой системы.

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

avmich>А кроме того :) $2k+ уже выглядят как-то странно... и особенно, что при этом в них нет хотя бы одного (!) гигабайта памяти...

Гм. Гигабайт, вообще-то там как раз есть. А что до цен - дык, 1U. Один корпус стоит только от $250 за самый отстой до $500 за родной Intel. А те же Chenbro - вообще к $600 приближаются. Ну а ещё нормальная мать - $500 (и не важно, 5700-й это чипсет или SerwerWorks). Вот уже пол-компа. Гигабайт регистровой памяти с ECC, неважно, SDRAM или DDR, стоит ещё $300... Да что я повторяюсь - сверху, вон, раскладка цен есть.

avmich>Не выкручивайте скорость винтами, они механические... Увеличивайте объём ОЗУ (на серверных платах разъёмов много) и частоту процессоров...

Похоже, ты нифига переписку не читаешь. Я не собираюсь ничего выкручивать винами - одиночный SCSI без RAID'а. Да ещё и десятитысячник. Или ты тем, кто RAID ставить предлагает?

avmich>(Да, в скобках, как человек, работавший с 1998 до 2000 года в индустрии жёстких дисков - самые качественные лиски в 2000 году считались от IBM, затем - от Fujitsu)

Ну, я итак на IBM уже решился.
   
+
-
edit
 

=KRoN=
Balancer

администратор
★★★★★
KeyOS>Вот тут вы для меня америку открыли. Сам будучи програмером под эти самые unix системы такое заявление слышу впервые. Для начала могу сказать, что одно другому (много- поточность/процессность) не мешает.

Естественно, не мешает. Но, как уже отметили, многопоточность появилась совсем недавно. И неважно, что она принципиально возможна, важно то, что это пока мало кем используется. Тот же fork() порождает именно новый процесс, а не поток. Даже в Perl'е.

=KRoN=>>Ты упускаешь, что CGI-процессов в системе может быть много. Кроме того, внутри одного CGI-запроса может тоже быть много процессов.
KeyOS>Нет, не упускаю.

Ну так, соответственно, каждый процесс может идти на своём сервере. Или это я что-то упускаю?

KeyOS>Про АвиаТОП честно говоря не знал.
А ресурсов, как раз, жрёт много. Его из-за этого с пары хостингов уже выгоняли, один раз даже без предупреждения. Кстати, он как раз для статистики MySQL базу использует.

KeyOS>Опять не понял, а зачем доступ. Неужели некому раз в день кассету поменять ?

Теоретически возможно, но практически это в обязанность хостера не входит, потому надеяться на их обязательность не стоит.
   
+
-
edit
 

=KRoN=
Balancer

администратор
★★★★★
Да, ещё по поводу сервера Олега Лазутченко. Никому среди ваших знакомых 2U-сервер не нужен? Точную конфигурацию так и не знаю, но 1Гб SDRAM, мать Intel, Dual P3-850, два IDE-винта по 80Гб от IBM, slim-сидюк и всё такое. Год назад был взят за >$2000, в работе так и не был.
   

KeyOS

новичок
=KRoN=>В unix-системах многопоточность, как правило, не используется, только многопроцессность. Что же до UBB - сколько одновременно на форумах пасётся людей, поисковых систем, роботов - столько, помноженное в несколько раз (Apache + Perl + PHP + ... - на каждого свой экземпляр) работает процессов.

Вот тут вы для меня америку открыли. Сам будучи програмером под эти самые unix системы такое заявление слышу впервые. Для начала могу сказать, что одно другому (много- поточность/процессность) не мешает. Любую многопроцессную задачу пожно выполнить как многопоточную. Дело в предпочтении и экономии тех самых ресурсов, которые экономятся чуть лучше в многопоточной архитектуре. А откуда у вас такие данные если не секрет ?

=KRoN=>Ты упускаешь, что CGI-процессов в системе может быть много. Кроме того, внутри одного CGI-запроса может тоже быть много процессов.

Нет, не упускаю.

=KRoN=>Обычный top, в принципе, много может сказать.

Простите, но обычный top к сожалению ничего сказать не может. Это красивая программа показывающая вам состояние системы с минимальным шагом в одну секунду. Ею надо пользоваться для беглого просмотра, но профайлинг к сожалению не из той области.

=KRoN=>Нет. Для этого есть ImageMagick - кстати, все местные иконки, превьюшки и т.п. генерятся им. А ещё следует помнить про такую штуку, как АвиаТОП - это ~100тыс показов баннера в день. Баннер, хоть и кешируется (что не есть хорошо, просто генерацию на каждый запрос система сейчас не тянет), но генерится на лету.

Про АвиаТОП честно говоря не знал.

=KRoN=>Обычно у нормальных провайдеров машинный зал закрытое и охраняемое помещение, доступ в которое надо отдельно заказывать.

Опять не понял, а зачем доступ. Неужели некому раз в день кассету поменять ?
   
+
-
edit
 

=KRoN=
Balancer

администратор
★★★★★
ruh>KRoN, Р3(1400) с 512 к кэша выделяет тепла в 1.5 раза меньше чем ксеончик(1800)

Угу.

ruh>Тоесть боюсь наидешевейшим корпусом не отделаешься.

"Доктор, меня игнорируют" - я уже несколько раз писал, что хочу брать Intel SR1300, как раз под матери CW2 под Xeon. Интеловский корпус, рекомендованный к интеловской матери интелом же :) Надеюсь, всё потянет. Цена - $500+.

ruh>Учти, что кулера стандартные под Р4 в 1U и близко не лезут.

Естественно, я буду брать боксовые Xeon'ы под 1U! ~$195..$200 за штуку.

Кстати, по поводу требований сервера. Форумы опять сейчас легли от перегрузки процессора. Average load доходил до 30%! :eek:

Заставил админа поставить Compress::Zlib вместо вызова внешнего gzip'а - может, чуть полегчает.

Если кому интересна статистика по Апачу -
   

KeyOS

новичок
=KRoN=>Естественно, не мешает. Но, как уже отметили, многопоточность появилась совсем недавно. И неважно, что она принципиально возможна, важно то, что это пока мало кем используется. Тот же fork() порождает именно новый процесс, а не поток. Даже в Perl'е.

Заключительные реплики ;)
Как, что работает я знаю по моему очень хорошо.
5 лет уже с этими самыми потоками работаю и не совсем понял, что такое "появились недавно". Не на линуксах правда, но не из-за того, что там их не было, а по личным предпочтениям.
Экскурс в многопоточность/процессность был мной сделан как небольшое отступление и на данный момент к теме не относится.
Вся идея была дать понять, что если есть возможность, то лучше работать с однопроцессорными системами. Просто игра далеко не всегда стоит свеч и потратив лишние деньги можно обнаружить, что дополнительный процессор не помогает.

Насчет перехода на другие технологии тут очень посчитать до этого надо.

Если хотите могу предложить посильную помощь и попробовать проследить, что и где работает медленно и почему.
   
+
-
edit
 

Mishka

модератор
★★★
=KRoN=>Так а что толку-то? Вот если рискну перейти на Apache 2.x, да ещё сумею софт на mod_perl перевести - то реальная многопоточность появится. Хотя имеет ли смысл - потоки же на разные процессоры не раскидаешь? Или можно?

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


=KRoN=>Я тоже так считаю (и давно), но ещё не дожил до доверия MySQL. Как я уже упоминал, если меня внимательно читают, я уже несколько раз терял таблицы. И из-за глюков в скриптах, и из-за своих ошибок, и из-за глюков в самом MySQL. Пока там только

А какие глюки в нем, что вызывают потерю таблиц?

=KRoN=>кеши - это не так страшно, таблицы пересоздаются из файлов, но если там будет уникальная информация - то всё, труба. Чем файловая система лучше - там труднее одним махом целый раздел убить.

ну, это, никогда не набирал не из то директории:

rm *

или еще лучше

rm -r -f *

? По-моему, через эти грабли все проходят - особенно после форточек и переименованием файлов ren *.text *.txt


avmich>>Не выкручивайте скорость винтами, они механические... Увеличивайте объём ОЗУ (на серверных платах разъёмов много) и частоту процессоров...

А это как софт написан - если все через диски, то память не особо поможет.


=KRoN=>Похоже, ты нифига переписку не читаешь. Я не собираюсь ничего выкручивать винами - одиночный SCSI без RAID'а. Да ещё и десятитысячник. Или ты тем, кто RAID ставить предлагает?

В компьюетере все должно быть прекрасно - и процессор, и память, и диски. (С) :)

avmich>>(Да, в скобках, как человек, работавший с 1998 до 2000 года в индустрии жёстких дисков - самые качественные лиски в 2000 году считались от IBM, затем - от Fujitsu)

У меня на работе тоже в основном ИБМ были.
   
+
-
edit
 

Mishka

модератор
★★★
KeyOS>Как, что работает я знаю по моему очень хорошо.
KeyOS>5 лет уже с этими самыми потоками работаю и не совсем понял, что такое "появились недавно". Не на линуксах правда, но не из-за того, что там их не было, а по личным предпочтениям.

Да примерно тогда и появились. До этого или на vfork или нити не поддержаные ядром, работавшие в пространстве пользователя и диспетчер был там же. Т.е. о time slice не приходилось говорить. Да и с переносимостью проблемы. POSIX pthreads как раз и был ответом. Кстати, Крон, если будешь переносить свой софт в нити, то иши pthread всякие, а не fork-и.

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

Ага.

KeyOS>Если хотите могу предложить посильную помощь и попробовать проследить, что и где работает медленно и почему.

Давай, думаю Крон не обидится. Я хочу БД пощупать тоже - если Крон позволит.
   
+
-
edit
 

avmich

координатор

Даже если софт написан через обращения к дискам... то кэши в памяти могут до некоторой степени поправить ситуацию. Думаю, что до большой степени...
   
+
-
edit
 

=KRoN=
Balancer

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

Идея идеей, но я ж кидал ссылочку на "форумные" тесты систем. Средний прирост по скорости от перехода на двухпроцессорную систему, будь до AMD или Intel - 50%.

KeyOS>Если хотите могу предложить посильную помощь и попробовать проследить, что и где работает медленно и почему.

Увы, к Юкиной машине shell-доступа у меня нет. Ссылочку я уже давал. Могу подключить cgi-скрипт, выдающий результат top'а.
   
+
-
edit
 

=KRoN=
Balancer

администратор
★★★★★
Mishka>А какие глюки в нем, что вызывают потерю таблиц?

Если б я знал. Было однажды - раз и потёрлись две таблицы. В смысле обнулились (сами таблицы остались).

Mishka>ну, это, никогда не набирал не из то директории:
Mishka>rm *

Видишь ли, из скриптов с такими операциями очень редко приходится работать. А unlink по маске удалять не умеет :) А вот в DELETE параметры напутать в SQL-запросе, или криво сформировать его скриптом - гораздо проще.

Mishka>В компьюетере все должно быть прекрасно - и процессор, и память, и диски. (С) :)

m/ :beer::D
   
1 2 3 4 5 6 7

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru