[/b/] [/d/] [/tu/] [/a/] [/34/] [/ph/] [/wa/] [/cg/] [/t/]

[Burichan] [Futaba] [Gurochan] [Photon] - [Home] [Manage] [Archive]

[Return]
Posting mode: Reply
Leave these fields empty (spam trap):
Name
Link
Subject
Comment
File
Verification
Password (for post and file deletion)
  • Supported file types are: GIF, JPG, PDF, PNG
  • Maximum file size allowed is 20480 KB.
  • Images greater than 200x200 pixels will be thumbnailed.

File: 1306554178784.png -(105705 B, 400x600) Thumbnail displayed, click image for full size.
105705 No.60847  

http://wiki.apache.org/httpd/PrivilegeSeparation
насколько актуально написанное?
что выбрать?
производительность важна

>> No.60848  
File: 1306554773123.jpg -(1453466 B, 900x1350) Thumbnail displayed, click image for full size.
1453466

>>60847

> насколько актуально написанное?

Вполне актуально.

> что выбрать?

Зависит от задачи, количества пользователей, требуемой производительности, узкого места железа.

> производительность важна

Возможно апач/только апач не самый лучший выбор.

>> No.60849  
File: 1306559755882.jpg -(592735 B, 744x1052) Thumbnail displayed, click image for full size.
592735

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

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

вобщем, я так понимаю, что уход с апача может быть череват потерей совместимости с существующим кодом веб-приложений?

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

на настоящий момент крутится mpm_peruser и все кое как работает, но по ощущениям тупит и переодически вообще перестает отвечать. временно решено перезагрузкой каждый час по крону.

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

и еще на официальном сайте mpm_peruser писали что-то про то, что правильным будет скомпилить все non-threaded. надо будет проверить на предмет этого.

в нужном направлении мыслю?

это дженту, кстати.

>> No.60850  
File: 1306563326570.jpg -(393376 B, 1209x1014) Thumbnail displayed, click image for full size.
393376

>>60849

> по ощущениям тупит и переодически вообще перестает отвечать. временно решено перезагрузкой каждый час по крону

Свопится?

>> No.60856  
File: 1306598632301.jpg -(44076 B, 464x261) Thumbnail displayed, click image for full size.
44076

>>60850

в свопе лежит что-то, но вот дергает ли он диск - я не вижу, потому как нет постоянного физического доступа. надо наверное iotop поставить, да?

>> No.60857  
File: 1306600037755.png -(814826 B, 1217x752) Thumbnail displayed, click image for full size.
814826

>>60856
Если там лежит больше пары мегабайт то это плохой признак. Если оно у тебя уперается не в скорость CPU а в память/дисковую подсистему то стоит копать не в сторону увеличения процессорной производительности а в сторону уменьшения потребления памяти или увеличения объема таковой.

> iotop

Достаточно общей нагрузки на диск, iostat из app-admin/sysstat вполне хватит.

>> No.61048  
File: 1306841824965.jpg -(238510 B, 900x600) Thumbnail displayed, click image for full size.
238510

я тут решил сперва обновиться и это таки затянулось. давай временно отложим вопросы оптимизации и поговорим про совместимость версий php. я накатил 5.3.6, а было что-то из ветки 5.2 в результате чего всякое говно мамонта перестало работать с ошибками вида "Deprecated:" и этого говна тонны. как правильно поступить в этой ситуации? может есть какой-то режим обратной совместимости который можно как-то включить хотябы как временное решение?

>> No.61050  
File: 1306842332968.png -(433963 B, 560x800) Thumbnail displayed, click image for full size.
433963

>>61048
Ставь php 5.2 и используй как основную версию.

>> No.61102  
File: 1306892627086.jpg -(108320 B, 500x333) Thumbnail displayed, click image for full size.
108320

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

сейчас буду думать что дальше делать.

а пока такой вопрос - revdep-rebuild пытается притянуть какой-то x11-libs/qt-meta:3
как узнать что мне надо снести чтобы он не тянулся? наверняка мне это уже ненадо. сервак вообще когда-то десктопом был и с тех пор система не переставлялась, это где-то с 2004ого года. сейчас вот хочу заняться ей и вычистить все лишнее.

и еще, помню был способ узнать какой файл принадлежит к какому пакету. куда копать?

>> No.61103  

http://www.gentoo.org/doc/en/portage-utils.xml
вот, нашел полезное

>> No.61105  
File: 1306906324430.jpg -(73400 B, 480x640) Thumbnail displayed, click image for full size.
73400

>>61102

> как узнать что мне надо снести чтобы он не тянулся?
equery depends x11-libs/qt-meta
> способ узнать какой файл принадлежит к какому пакету
equery belongs [/path/to/]filename
>> No.61107  
File: 1306911875730.png -(79919 B, 505x514) Thumbnail displayed, click image for full size.
79919

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

>> No.61108  
File: 1306912895215.png -(707685 B, 1200x849) Thumbnail displayed, click image for full size.
707685

>>61107

equery depends packagename

же

>> No.61109  
File: 1306914375483.png -(114469 B, 390x380) Thumbnail displayed, click image for full size.
114469

>>61108
а.

>> No.61116  
File: 1306931566555.jpg -(25039 B, 550x375) Thumbnail displayed, click image for full size.
25039

>>61105

я нашел еще qfile и qdepends, но то что ты посоветовал лучше, тем более что qdepends выводит что-то совсем не то. там вообще три переменные, наверное часть ебилда: DEPEND, RDEPEND и PDEPEND. что они дефайнят? чисто интересно.

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

все так? может будут еще какие-то рекомендации?

а еще я думаю что в системе собралось значительное количество ничейных и просто сгенерированных софтом в процессе своей работы файлов. например всякого говна установленного вручную методом в духе make && make install или банальных логов, дампов и просто мусора который я разбросах руками за столько лет. существует какой-то автоматизированный сопособ выявления таких вещей? т.е. чтобы он показал все файлы которые не принадлежат никаким пакетам и при этом среди этих файлов выделил множество логов, множество служебных файлов созданных автоматически и множество файлов явно ручного происходжения, т.е. всех остальных.

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

вобщем, давай это обсудим

>> No.61118  
File: 1306934900358.jpg -(142040 B, 640x480) Thumbnail displayed, click image for full size.
142040

>>61116

> что они дефайнят? чисто интересно

Гугль, 4я ссылка: http://devmanual.gentoo.org/general-concepts/dependencies/

> если что-то вынести из ворлда - то при --depclean это вычищается, я правильно понял? и все зависимости очевидно тоже?

Верно. Можно сразу --unmerge делать, оно тогда и из world запись уберет и пакет удалит без зависимостей.

> и если в новой версии пакет перестает от чего-то зависеть, то --depclean это сносит, так?

Так. Если пакет слотовый и установленные версии явно не указаны то он оставит только последнюю версию, осторожней с этим.

> а если --depclean пытается вынести что-то явно нужное, то надо добавить это в world при помощи --noreplace

Тоже верно. Кстати не забудь после --depclean сделать revdep-rebuild.

> существует какой-то автоматизированный сопособ выявления таких вещей?

Не встречалось. Если мусор не занимает особо много места и не мешает нормальной работе то проще просто оставить его в покое и не тратить время на выяснение "чего же тут у меня еще лишнего". Если же просто прибить все файлы, не принадлежащие ни одному из установленных пакетов, то это по сути будет равносильно перестановке системы и скорее всего под раздачу могут попасть какие-то нужные костыли или просто файлы, создаваемые софтом во время работы, например sql-базы. Отличный способ найти не ротейтящиеся логи - искать файлы размером в гиг и больше.

>> No.61120  
File: 1306936005550.jpg -(585506 B, 1818x1228) Thumbnail displayed, click image for full size.
585506

>>61118

>искать файлы размером в гиг и больше.

а может по времени создания лучше? обратить внимание на файлы которые постоянно обновляются и слишком старые файлы.

а вообще вот интересный тред: http://forums.gentoo.org/viewtopic-t-853405-start-0.html

>> No.61121  
File: 1306936465822.jpg -(208092 B, 1116x792) Thumbnail displayed, click image for full size.
208092

>>61120

> а может по времени создания лучше? обратить внимание на файлы которые постоянно обновляются и слишком старые файлы.

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

>> No.61133  
File: 1306943427316.jpg -(32529 B, 604x374) Thumbnail displayed, click image for full size.
32529

>>61121

>после недавнего обновления системы

подождать недельку

>почти все редко обновляемые пакеты

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

>пользовательские файлы

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

>размер же современных жестких дисков

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

>> No.61134  
File: 1306944722303.jpg -(745728 B, 800x1000) Thumbnail displayed, click image for full size.
745728

>>61133
Смотри сам, как по мне, так проще для устранения нехватки места удалить один файл на 10G чем выискивать тысячу по 10M.

>> No.61136  

>>61134
мне интересно даже не столько удалять их, сколько представлять себе технологию их массового удаления на случай если это понадобиться. а так да, я пока тоже делать этого не буду, мой интерес больше теоретический.

>> No.61152  
File: 1306959494917.gif -(144517 B, 640x480) Thumbnail displayed, click image for full size.
144517

Насколько часто желательно менять жесткие диски при использовании 24/7, чтобы снизить риск их внезапной смерти? Каковы заявленные производителями сроки и насколько они соотносятся с реальностью? Случаи, когда массово летят сигейты из неудачных партий не рассматриваем.

>> No.61164  
File: 1306968234092.jpg -(85392 B, 417x426) Thumbnail displayed, click image for full size.
85392

>>61152
лично я слежу за смартстатусом и не парюсь, пока там все чисто - менять ненадо. если блок питания хороший, диски работают 24/7 на чистом питании в кондиционируемом помещении, то они почти вечные. некоторые производители заявляют ресурс(MTBF) больше миллиона часов. я считал - это что-то около 100 лет. думаю что это правда или почти правда. по крайней мере около 40 000 часов под нгрузкой(squid) без малейших признаков износа - это реальность которую я наблюдаю своими глазами. и это далеко не предел, я думаю.

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

>> No.61166  
File: 1306968507734.jpg -(81251 B, 1600x1200) Thumbnail displayed, click image for full size.
81251

олсо да, из винтов существует только Hitachi, IBM и Seagate(по убывающей надежности), ничего другого я не трогаю даже 18метровой палкой. обосновать немогу.

>> No.61169  
File: 1306976566602.jpg -(27155 B, 400x338) Thumbnail displayed, click image for full size.
27155

http://www.peruser.org/trac/peruser/wiki/PeruserGettingStarted
черт подери, тут же все написано, предельно понятно и совершенно однозначно. и стоило столько мучаться.

о результатах доложу, со временем

ОП

>> No.61170  
File: 1306979444945.jpg -(37759 B, 586x583) Thumbnail displayed, click image for full size.
37759

>>61152
Сильно от удачи зависит. Некоторые могут в течении года концы отдать, некоторые - наработать десяток лет при температуре под 60 градусов. Про бекап лучше не забывать в любом случае, если тебе дорога информация на диске. Использование рейда с избыточностью так же будет неплохой идеей.

>> No.61173  
File: 1306982306960.jpg -(50018 B, 323x400) Thumbnail displayed, click image for full size.
50018

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

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

в прицнипе рэйд вообще снимает вопрос надежности носителей, количество лучше качества в данном вопросе.

>> No.61174  
File: 1306983758001.jpg -(1040104 B, 1024x1024) Thumbnail displayed, click image for full size.
1040104

>>61173

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

Это уже зависит от ценности хранящихся там данных и уровня паранои того, кто отвечает за их сохранность.

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

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

>> No.61175  
File: 1306985155208.jpg -(58384 B, 600x385) Thumbnail displayed, click image for full size.
58384

ОП на связи

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

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

вобщем принимаю советы по дальнейшей оптимизации

>> No.61176  
File: 1306985702250.png -(94768 B, 640x500) Thumbnail displayed, click image for full size.
94768

>>61174

>Это уже зависит от ценности хранящихся там данных и уровня паранои того, кто отвечает за их сохранность.

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

>Если данные часто обновляются и быстро устаревают, например в случае БД, то рейд предпочтительней бекапов, если возможно использовать только что-то одно.

ну только если это что-то типа кэша. или приведи пример.

>далеко не всегда можно заменить винт, не останавливая систему

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

алсо можно всегда держать хотсвоп, даже на системах не поддерживающих хотплаг.

а вообще рэйд это даже близко не замена бэкапа:

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

>> No.61177  
File: 1306987077395.jpg -(912280 B, 1400x1400) Thumbnail displayed, click image for full size.
912280

>>61175

> что бы такого еще сделать?

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

> какое-нибудь кэширование? как это обычно делается?

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

> прон обычно не бэкапят, больше ничего такого на ум не приходит.

Кеш уже упомянутого в треде squid, всякие tmp, distfiles и/или затянутые из репозитория пакеты, логи итд.

> ну только если это что-то типа кэша. или приведи пример.

Любая быстро изменяемая база, например с транзакциями.

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

Тоже верно.

> неудачно сгоревший блок питания убивает оба винта

Довольно редкое явление для серверных БП.

> молния ударившая в провода сжигает вообще все что связано гальванически. своими глазами видел.

Боюсь даже спросить, во что после этого превратился упс.

> вирусня, взломщик или кривые руки

Первые два фактора являются частичным следствием третьего и от них рейд поможет только при использовании файловой системы с снапшотами.

>> No.61196  

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

>> No.61201  

>>61196
mdadm умеет висеть в режиме демона и следить за винтами, при смерти одного из них присылать на мыло сообщение об этом

>> No.61212  

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

>> No.61214  
>Кеш уже упомянутого в треде squid, всякие tmp, distfiles и/или затянутые из репозитория пакеты, логи итд.

бэкапят систему вообще говоря всегда выборочно, так что да

>Боюсь даже спросить, во что после этого превратился упс.

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

>рейд поможет только при использовании файловой системы с снапшотами.

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

>> No.61215  

>>61212
И чем мне в этом случае поможет рейд? Тем, что у меня будет 2 одинаковые копии испорченных данных?

>> No.61216  

>>61214
В таком случае эффективно для бэкапов пару внешних хардов, подключаемых поочередно.

>> No.61217  

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

>> No.61218  

>>61216
совершенно верно. или NAS в том или ином виде. главное гальванически развязать получше, либо отключив либо расположив в другой географической локации.

>> No.61221  
File: 1307039568491.gif -(627974 B, 636x474) Thumbnail displayed, click image for full size.
627974

вобщем ОП снова на связи. докалыдваю о том, что установил http://eaccelerator.net/ и серваку дичайше полегчало, очень рекомендую. документация на сайте краткая и толковая, обязательно почитай.

и еще один небольшой вопрос - а зачем ставят nginx перед апачем? толку кэшировать статику? что мешает апачу отдать ее самостоятельно с той же скоростью?

и умеет ли что-либо кэшировать динамику? и если да, то что и как?

хотя это уже перфекционизм начинается, в принципе на настоящий момент мои запросы по производительности удовлетворены полностью, не смотря на ужасающее качество самих скриптов.

>> No.61238  
File: 1307068265190.jpg -(174122 B, 1000x773) Thumbnail displayed, click image for full size.
174122

>>61214

> бэкапят систему вообще говоря всегда выборочно

Не всегда. Полный бекап системы развернуть куда быстрее чем выборочный.

> а как помогают снапшоты, можешь по шагам описать?

Время от времени фс дается команда сделать снимок. Потом этот самый снимок можно примонтировать как отдельную фс r/o и иметь возможность прочитать то, что предоставляла из себя фс на момент создания этого снапшота.
>>61221

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

Статику он умеет отдавать самостоятельно, причем делает это в разы быстрей апача за счет использования epoll и sednfile().

> умеет ли что-либо кэшировать динамику? и если да, то что и как?

Тот же nginx при соответствующей настройке, squid при ней же.

>> No.61384  
>Не всегда. Полный бекап системы развернуть куда быстрее чем выборочный.

вообще говоря восстанавливать систему из бэкапов нужно настолько редко, что это неважно тащем-та. впрочем бывает реально кровавый энтерпрайз, где потеря данных может обернутся массовыми расстрелами, а каждая минута даунтайма - расстрелами обычными, не массовыми. но в таких случаях разумно применять системы автоматического деплоймента конфигураций. т.е. ты просто в считанные минуты ставишь дефолтную систему(даже специальным скриптом), поднимаешь там паппет-клиент, подключаешь к хосту нужные описания конфигураций и за несколько минут все это накатывается, после чего останется только подсунуть ему данные и ПРОФИТ. один минус у этого подхода, puppet - говно невыносимое.

>Время от времени фс дается команда сделать снимок.

представь себе что что-то сошло с ума и начало массированно портить данные. снэпшот разумного размера переполнится за считанные минуты после чего станет бесполезен. или я чего-то не учел?

>Статику он умеет отдавать самостоятельно, причем делает это в разы быстрей апача за счет использования epoll и sednfile().

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

>epoll и sednfile()

а в чем суть? сугубо любопытство

>Тот же nginx при соответствующей настройке, squid при ней же.

но КАК можно кэшировать динамику? можешь на пальцах объяснить?

>> No.61387  
File: 1307165831703.png -(1113839 B, 1400x992) Thumbnail displayed, click image for full size.
1113839

>>61384

> восстанавливать систему из бэкапов нужно настолько редко, что это неважно тащем-та

В таком случае это ничуть не лучше отсутствия бекапов и восстановлению системы с нуля в случае ЧП.

> представь себе что что-то сошло с ума и начало массированно портить данные. снэпшот разумного размера переполнится за считанные минуты после чего станет бесполезен. или я чего-то не учел?

Реализации с запретом перезаписи данных снапшота.

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

Как правило да. Для мелких проэктов и при отсутствии DDoS малоактуально.

> а в чем суть? сугубо любопытство

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

> но КАК можно кэшировать динамику? можешь на пальцах объяснить?

При первом запросе - параллельно положить в кеш, при следующем - отдать из кеша, если он не устарел.

>> No.61448  

>>61387

>В таком случае это ничуть не лучше отсутствия бекапов и восстановлению системы с нуля в случае ЧП.

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

>Реализации с запретом перезаписи данных снапшота.

это означает по факту, запрет записи на ФС после наполнения снапшота, т.е. падение системы - отличная дыра для DoS.

>при отсутствии DDoS малоактуально

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

>при следующем - отдать из кеша, если он не устарел.

воот! а как мижно определить устарел ли кэш не выполнив скрипт? а если скрипт выполнен, то кэш уже не имеет смысла.

>> No.61494  
File: 1307249969513.jpg -(246941 B, 640x640) Thumbnail displayed, click image for full size.
246941

>>61448

> это означает по факту, запрет записи на ФС после наполнения снапшота

Просто не стоит забывать о необходимости иметь куда больше места на фс при использовании снапшотов.

> да ктож досит по статике то?

Несколько сотен запросов в секунду и апач уходит в себя, всерьез и на долго, даже если статику отдает на них.

> а как мижно определить устарел ли кэш не выполнив скрипт?

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

>> No.61495  

>>61494

>Просто не стоит забывать о необходимости иметь куда больше места на фс при использовании снапшотов.

хм.. ну технически - это вариант, хотя помоему странно.

>Несколько сотен запросов в секунду и апач уходит в себя, всерьез и на долго, даже если статику отдает на них.

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

>Например определив условия устаревания этого кеша, скажем пол часа при условии не передачи печенек со стороны клиента.

странные условия. можешь объяснить почему они полезны? кроме того - а как кэш о них узнает? при помощи HEAD запроса?

>> No.61496  
File: 1307257026670.jpg -(461810 B, 600x750) Thumbnail displayed, click image for full size.
461810

>>61495

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

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

> странные условия. можешь объяснить почему они полезны?

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

> кроме того - а как кэш о них узнает? при помощи HEAD запроса?

Кеш обычно ставится между веб сервером, исполняющим скрипты и посетителями сайта, нередко так же еще и выступает в роли load-balancerа.

>> No.61566  
File: 1307308969426.jpg -(144593 B, 1024x768) Thumbnail displayed, click image for full size.
144593

>>61496
то есть, выходит, условия выдачи из кэша надо где-то настроить. как это делается на практике обычно?

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

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

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

>> No.61582  
File: 1307329635254.jpg -(214562 B, 1024x768) Thumbnail displayed, click image for full size.
214562

вобщем я понял

мне в голову не могло придти, что в среднем чайлд апача сжирает от 10 до 30 мегов RES, то есть физической памяти и около 100 VIRT, то есть RES+SWAP. поэтому совершенно не удивительно, что система с 1.2гигами оперативки валилась, если на ней запускалось несколько сотен чайлдов. я то думал что они ну мега по два весят.

вобщем у меня где-то наверное с 30 виртуалхостов, малонагруженным я дал по одному чайлду, а тяжелым по 3. ну и снизил таймауты для чайлдов которые висят в режиме ожидания. тепреь даже если весь этот пул выстрелит одновременно корч будут вращаться вполне себе живо или будет отдавать 503, но по факту это значит что он реально не справляется и увеличение пула или таймаутов мне тут не поможет. все так?

вобщем - чисто мой проеб был.

но тем не менее, откуда в чайлдах взялось столько веса? я пока не особо тщательно мерял, но отключение eaccelerator не особо то влияет на на этот показатель, кажется.

это интерпретатор пхп в каждом процессе, да?

может и правда, если вынести статику на nginx можно неслабо сэкономить памяти? сколько в среднем весит чайлд nginx?

кстати, а если бы в каждом процессе были включены треды, то это было бы эквивалентно тому, что при том же количестве процессов, а следовательно и памяти, было увеличено количество обработчиков?

а еще я столкнулся с таким эффектом, что при пуле в 1-2 процесса страница на которой допустим 20-30 превьюшек к фоткам грузится долго, причем сразу выстреливает около 60% всех фоточек или даже больше, потом еще 30%, а потом последние 1-3 превьюшки могут не догрузится вообще. чего ему нехватает? даже если процесс один - мог бы их все последовательно загрузить, пусть бы это даже заняло время. что ему мешает?

>> No.61583  

и кстати да, а умеет ли nginx менять UID в соответствии с vhost'ом? он же должен быть совместим с моей моделью изоляции юзеров

>> No.61587  
File: 1307348198210.png -(762604 B, 1275x1751) Thumbnail displayed, click image for full size.
762604

>>61582
Довольно сложно сходу не заметить что система активно лезет в своп, хотябы по тому, что он используется.

> откуда в чайлдах взялось столько веса?

Апач довольно тяжелая штука.

> интерпретатор пхп в каждом процессе, да?

Естественно, если ты используешь пхп как модуль к апачу.

> сэкономить памяти?

Памяти - нет.

> сколько в среднем весит чайлд nginx?

Зависит от включенных модулей, а так порядка 10 метров на воркера и метра на мастера.

> если бы в каждом процессе были включены треды, то это было бы эквивалентно тому, что при том же количестве процессов, а следовательно и памяти, было увеличено количество обработчиков?

Да, только у пхп при таком режиме могут быть проблемы.

> чего ему нехватает?

Обработчиков. Браузер может устанавливать сразу пачку соединений с сервером для ускорения работы, а вот сервер у тебя эту пачку одновременно обработать не может.
>>61583
Не умеет.
>>61566

> режет им полосу на отдачу до очень малого значения

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

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

top/htop, сортировка по %MEM.

>> No.61602  
File: 1307356352720.jpg -(83497 B, 720x400) Thumbnail displayed, click image for full size.
83497

>>61587

>Довольно сложно сходу не заметить что система активно лезет в своп, хотябы по тому, что он используется.

фишка какбэ в том, что даже с выключенным апачем в свопе что-то лежит. а индикатор hdd я не вижу, физического доступа нет. надо поставить iotop.

>а вот сервер у тебя эту пачку одновременно обработать не может.

в доках к mpm_peruser написано, что мультиплексор будет отдавать процессы на обработку по мере освобождения обработчиков, но не более таймаута. таймаут у меня стоит дичайших 40 секунд, но тем не менее битые пикчи(или css, к примеру) он выдает намного раньше. это баг? или может у мультиплексора просто ограничен размер очереди и в зависимости от того, насколько она заполнена на момент заргузки страницы с моей стороны у меня не грузится то или иное число пикч. похоже на правду?

>top/htop, сортировка по %MEM.

с top уже освоился, на очереди htop и iotop.
кстати, а умеет ли топ фильтрвать вывод по названию файла из которого был запущен процесс? т.е. чтобы оно мне показало только то, что называется apache2 к примеру. не нашел такого, хотя по логике оно должно существовать.

>> No.61616  
File: 1307362257928.jpg -(327196 B, 1335x977) Thumbnail displayed, click image for full size.
327196

>>61602

> с выключенным апачем в свопе что-то лежит

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

> индикатор hdd
iostat -xm 2

Получше всяких индикаторов hdd и для каждого блочного устройства в отдельности.

> он выдает намного раньше

Возможно что он отбрасывает медленные соединения при попытке запросить что-то еще.

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

top нет, htop умеет древовидный режим, если ширины экрана не хватает на то, чтобы посмотреть, что именно там запущено то используй ps auxf | more

>> No.61696  
File: 1307429566709.jpg -(60355 B, 500x387) Thumbnail displayed, click image for full size.
60355
>iostat -xm 2

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

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

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

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

>> No.61714  
File: 1307439084365.png -(126200 B, 300x300) Thumbnail displayed, click image for full size.
126200

>>61696

> медленные в каком смысле и отбрасывает по какому принципу?

Скорее всего придется ковырять исходники, чтобы понять это.

> никуда не исчезают

И пусть живут себе дальше. Или это проблема? Попробуй ограничить общее число форков в таком случае.

>> No.61807  
File: 1307489877161.png -(2042471 B, 896x1285) Thumbnail displayed, click image for full size.
2042471

>>61714

>Скорее всего придется ковырять исходники, чтобы понять это.

к такому я наверное пока не готов

>И пусть живут себе дальше. Или это проблема? Попробуй ограничить общее число форков в таком случае.

еще какая проблема - памяти нехватает. а если ограничить - получается по одному форку на виртуал-хост, тогда не работает толком нихера.

вобще я решил полюбому покупать сегодня-завтра второй гиг памяти, надеюсь это решит проблему. а если не решит, я вот что нашел: http://wiki.apache.org/httpd/DifferentUserIDsUsingReverseProxy
вариант хороший и избыток памяти тут будет очень кстати. только вот подумалось, а стоит ли использовать в качестве реверс-прокси именно апач, может лучше nginx? и существуют ли более-менее стандартные способы запуска множества апачей в gentoo?

>> No.61809  
File: 1307490796755.jpg -(361121 B, 800x800) Thumbnail displayed, click image for full size.
361121

>>61807

> второй гиг памяти

Одного гига на 30 юзеров явно мало, даже если все от одного uidа работать будет.

> http://wiki.apache.org/httpd/DifferentUserIDsUsingReverseProxy

Фактически те же яйца, что у тебя сейчас, только в профиль.

>> No.61813  

>>61809

>Одного гига на 30 юзеров явно мало

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

>Фактически те же яйца, что у тебя сейчас, только в профиль.

пишут просто, что это решение готово к продакшну, в отличие от mpm_peruser.

>> No.61815  
File: 1307494296835.jpg -(192216 B, 600x600) Thumbnail displayed, click image for full size.
192216

>>61813

> пишут просто, что это решение готово к продакшну, в отличие от mpm_peruser.

Кажется у тебя проблемы совсем не из-за mpm_peruser.

>> No.61817  

>>61815
ну вот смотри, малопосещаемый виртуалхост, галерейка одного чела, он туда фоточки складывает. дал ему три обработчика, но если на одной странице больше 20 превьюшек - часть не грузится. помоему это ненормально. я что-то делаю не так?

ситуацию контролирую сразу после перезапуска апача, на момент когда память еще не сожрана.

>> No.61820  

вобщем, я кажется нашел странное решение проблемы. вот с таким вот значением: ProcessorWaitTimeout 30 10 оно стабильно работает даже с малым количеством воркеров. пусть и медленно, но почти ничего не пропускает.

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

докуплю памяти - просто увеличу количество воркеров и попытаюсь так и оставить.

>> No.61913  

вобщем купил еще гиг, где-то завтра поставлю.

есть еще мысль проц заменить, выяснилось что в 478 сокет дофига чего становится намного более производительного чем селерон 1.7ГГц. посоветуй что ли камень который станет в мою плату, вот она: http://www.ecs.com.tw/ECSWebSite/Product/Product_Detail.aspx?CategoryID=1&DetailID=39&DetailName=Feature&MenuID=24&LanID=0

и насколько они вообще отличаются по производительности? например сегодня был на барахолке, мне за P4 extreme edition заломили $70, в то время как например celeron D трехгигагерцовый стоил всего 15. стоит ли вообще этим заниматься?

менять все вместе с платой пока не хочу, думаю потом сразу на MIPS или ARM соскочить.

>> No.61915  
File: 1307631302425.jpg -(1790784 B, 1200x1440) Thumbnail displayed, click image for full size.
1790784

>>61913

> за P4 extreme edition заломили $70

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

> на MIPS или ARM соскочить

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

>> No.61923  

>>61915

>поскольку покупать его рано или поздно все равно придется

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

>высокой производительности от них ждать не стоит

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

>> No.61977  
File: 1307688603516.jpg -(470539 B, 1000x1000) Thumbnail displayed, click image for full size.
470539

>>61923

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

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

> обычно их 16 в арм сервере

В тех же спарках 16 ядер далеко не предел. Стоит много конечно, но с другой стороны производительность на мегагерц у спарков в несколько раз выше чем у x86 (у x86 в несколько раз выше чем у ARM или MIPS).

>> No.62001  
File: 1307695614224.jpg -(36678 B, 716x544) Thumbnail displayed, click image for full size.
36678

>>61977

>у x86 в несколько раз выше чем у ARM или MIPS

Опечатка? Если код писался с учётом особенностей risc-архитектуры, они наоборот задвигают x86.

>> No.62003  
File: 1307696924378.jpg -(104705 B, 750x1300) Thumbnail displayed, click image for full size.
104705

>>62001

> Если код писался с учётом особенностей risc-архитектуры

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

>> No.62006  
File: 1307697632546.jpg -(124214 B, 849x607) Thumbnail displayed, click image for full size.
124214

>>62003
Тем не менее, этим занимаются. Частично проблему решают компиляторы. У ARM большие перспективы благодаря низкому энергопотреблению и меньшей необходимости в охлаждении. Кроме того, нередко под спецефические задачи сервера так или иначе придется писать собственные приложения.

>> No.62019  

>>61977

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

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

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

>В тех же спарках 16 ядер далеко не предел.

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

кстати ссылки на конкретные места где продаются ARM и MIPS решения тоже очень приветствуются ITT. я пока особо не видел конкретных предложений именно серверных плат с такими камнями, все больше SBC и производные.

>> No.62030  
File: 1307706977893.jpg -(516980 B, 1000x1000) Thumbnail displayed, click image for full size.
516980

>>62019

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

Можно просто переткнуть винт из старого сервака в новый. Если же у тебя тонкая подстройка под проц то пересобирать мир тебе возможно придется и после перетыкания проца.

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

Первая ссылка в гугле на офсайт с ценами: http://www.oracle.com/us/products/servers-storage/servers/sparc-enterprise/index.html

> ARM и MIPS решения тоже очень приветствуются ITT

http://habrahabr.ru/blogs/server_side_optimization/103430/ там же есть и ссылки на то, где оно продается.
На MIPS же похоже ничего мощнее домашних роутеров делать и не пытаются.

>> No.62056  
>Если же у тебя тонкая подстройка под проц то пересобирать мир тебе возможно придется

именно такая. но на самом деле это довольно безболезненная операция, просто время отнимет.

>Первая ссылка в гугле на офсайт с ценами

там от 18 кусков цены, профита не получается никак, даже близко. за эти деньги можно купить несколько десятков х86 десктопов + оплатить электричество на весь их жизненный цикл. кроме того это вообще не мой бюджет, мой $500-1000, я же на нем не зарабатываю.

тем не менее, если существуют спарки подоступнее - буду очень рад посмотреть.

>http://habrahabr.ru/blogs/server_side_optimization/103430/ там же есть и ссылки на то, где оно продается.

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

>На MIPS же похоже ничего мощнее домашних роутеров делать и не пытаются.

ложно. существует решение от lemote, 16ядерная серверная плата, но цену я так и не узнал, хотя даже писать им пытался. алсо китайский суперкомпьютер из последних вполне себе на mips. самый производительный в мире на настоящий момент, если я не ошибаюсь.

http://en.wikipedia.org/wiki/Lemote
http://www.lemote.com/en/products/cpu/2010/0310/114.html
я правда больше года назад читал по этим ссылкам, может там что и изменилось, проверь, мне лень сейчас.

>> No.62057  
File: 1307730570245.png -(940074 B, 900x1200) Thumbnail displayed, click image for full size.
940074

>>62056

> там от 18 кусков цены, профита не получается никак, даже близко. за эти деньги можно купить несколько десятков х86 десктопов + оплатить электричество на весь их жизненный цикл

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

> если существуют спарки подоступнее - буду очень рад посмотреть

Можно на e-bay поискать что-нибудь из предыдущего поколения спарков, б/у.

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

На мипсе ничего в TOP500 нету, http://www.top500.org/stats/list/36/procfam . Tianhe-1A же построен на ксеонах с теслами.

>> No.62102  
File: 1307777266359.jpg -(169711 B, 815x566) Thumbnail displayed, click image for full size.
169711

>>62057

>за счет более высокого класса надежности и производительности не только по CPU но и по периферии и шинам.

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

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

>Впрочем если твое решение легко ложиться на кластер

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

впрочем это не понадобится.

>Можно на e-bay поискать что-нибудь из предыдущего поколения спарков, б/у.

можно, но я уже говорил про БУшку.

>На мипсе ничего в TOP500 нету

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

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

вобщем проц покупать надо. пипл говорит что P4XE у меня не заработает, потому что частота шины 533, тогда как у него 800 и мне надо смотреть как я понял Р4 2400-2660-2800/533/512 на ядре вроде бы Northwood, так? сколько он тепла выделяет, кстати?

но перед тем как я его куплю еще можно попробовать покрутить приоритеты по процессору между юзерами. я вот сейчас попробовал потыкать /etc/security/limits.conf, но явное указание параметра nice для одного из юзеров вообще не отразилось в выводе top. может мне в ядре чего-то нехватает или эти изменения каким-то образом применить надо?

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

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

пикрандом

>> No.62104  
File: 1307780130804.png -(643273 B, 627x885) Thumbnail displayed, click image for full size.
643273

>>62102

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

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

> с апгрейдом

Обычно проще просто купить новый сервер.

> Р4 2400-2660-2800/533/512 на ядре вроде бы Northwood, так?

Ищи что-нибудь из SL6K7, SL6JJ, SL6QC, SL6S5, SL6SM, SL7E8, SL8B3, SL8JX, SL88G, SL7D8, SL7E2, SL7PK. Олсо шина у тебя на материнке не гонится?

> LA никуда не рассасывается

Попытайся выяснить, что же у тебя его съедает.

ps ax | grep -v S

например.

>> No.62117  
File: 1307791994059.jpg -(79112 B, 604x454) Thumbnail displayed, click image for full size.
79112

>>62104

>Вероятность такого события близка к вероятности выигрыша в лотерею.

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

>обычно проще просто купить новый сервер.

так это все деньги. а десктоп я вот ща обновляю всяким говном по цене песка.

>SL6K7, SL6JJ, SL6QC, SL6S5, SL6SM, SL7E8, SL8B3, SL8JX, SL88G, SL7D8, SL7E2, SL7PK

а что за обозначения такие? никогда прежде не интересовался.

>Олсо шина у тебя на материнке не гонится?

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

>Попытайся выяснить, что же у тебя его съедает.

вроде как все понемногу

>ps ax | grep -v S

попробую так

>> No.62120  
File: 1307792696219.png -(3771 B, 100x100) Thumbnail displayed, click image for full size.
3771

>>62117

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

Довольно спорный вопрос. За 3-5 лет непрерывной эксплуатации на десктопе обязательно чего-нибудь да сломается.

> а что за обозначения такие? никогда прежде не интересовался.

Модели процессоров же. http://ark.intel.com/Product.aspx?spec=%modelname% где %modelname% меняешь на что-нибудь из перечисленного.

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

Батарейку менять не пробовал?

> вроде как все понемногу

Гремлины?

>> No.62121  
>SL6K7, SL6JJ, SL6QC, SL6S5, SL6SM, SL7E8, SL8B3, SL8JX, SL88G, SL7D8, SL7E2, SL7PK

http://en.wikipedia.org/wiki/List_of_Intel_Pentium_4_microprocessors

пытаюсь разобраться. SL6PG ты пропустил случайно? и уверен ли ты насчет того, что будет работать prescott, но не будет работать HT?

и пишут ли эти буковки на самом корпусе камня?

>> No.62122  
File: 1307793118655.jpg -(502892 B, 750x775) Thumbnail displayed, click image for full size.
502892

>>62121

> SL6PG ты пропустил случайно?

800MHz шина же.

> и уверен ли ты насчет того, что будет работать prescott, но не будет работать HT?

SL6K7 с HT например.

> пишут ли эти буковки на самом корпусе камня?

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

>> No.62123  
File: 1307793603736.jpg -(21854 B, 300x400) Thumbnail displayed, click image for full size.
21854
>Довольно спорный вопрос. За 3-5 лет непрерывной эксплуатации на десктопе обязательно чего-нибудь да сломается.

блок питания у меня таки погорел один раз где-то лет за 5, но подмена ему нашлась сразу же. сгорел FSP, что интересно, причем с огромным запасом по мощности. и это, кстати, не единичный случай. со злости и в спешке запилил туда xilence на 550W. хороший вариант? подменка просто была из разряда SuperHujnya 250W peak power и было очень стремно пока она там стояла.

>Батарейку менять не пробовал?

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

>Гремлины?

ну там порядка 80 обработчиков и каждый висит сверху топа и и сжирает с переменным успехом от 1 до 3х процентов проца. и LA держится на 30-40 стабильно. после перезапуска все начинает летать. причем, что интересно, обычно в топе висят только два нагруженых сайта, а в момент наплыва в топе оказываются почти все. реально странное поведение.

>> No.62124  
File: 1307794147557.jpg -(55675 B, 649x338) Thumbnail displayed, click image for full size.
55675

>>62122

>SL6PG ты пропустил случайно?
>800MHz шина же.

http://en.wikipedia.org/wiki/List_of_Intel_Pentium_4_microprocessors
http://www.cpu-world.com/sspec/SL/SL6PG.html
http://ark.intel.com/Product.aspx?spec=SL6PG
здесь иное пишут, проверь

>SL6K7 с HT например.

точно, не заметил. а prescott точно не заработает?

>> No.62127  
File: 1307794381118.jpg -(1254990 B, 1280x800) Thumbnail displayed, click image for full size.
1254990

>>62123

> блок питания у меня таки погорел один раз где-то лет за 5, но подмена ему нашлась сразу же

А так бы просто работал на одном из двух.

> хороший вариант?

Сгореть может любой. Особенно от молнии в проводах.

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

Ты уверен что там показывается напряжение именно на батарейке а не скажем на PCI-нише?

> ну там порядка 80 обработчиков и каждый висит сверху топа и и сжирает с переменным успехом от 1 до 3х процентов проца

Они что-то обрабатывают или просто висят? Текущие соединения смотрел?

>> No.62128  
File: 1307794656755.jpg -(459356 B, 800x600) Thumbnail displayed, click image for full size.
459356

>>62124

> здесь иное пишут, проверь

Да, похоже ошибочка вышла.

> а prescott точно не заработает?

Должен тоже работать в принципе.

>> No.62130  
File: 1307795373667.jpg -(699809 B, 1680x1050) Thumbnail displayed, click image for full size.
699809

>>62127

>А так бы просто работал на одном из двух.

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

>Сгореть может любой. Особенно от молнии в проводах.

молнии небыло, кроме того там неебический бесперебойник размером со стиральную машину.

>Ты уверен что там показывается напряжение именно на батарейке а не скажем на PCI-нише?

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

>Они что-то обрабатывают или просто висят? Текущие соединения смотрел?

проц жрут, значит что-то делают, а вот насчет соединений - интересная мысль. вполне может быть что это DoS. типа кидаем запрос и сразу рвем соедниение. а как правильнее всего диагностировать наличие/отсутствие соединений? trafshow на ум приходит или netstat, но netstat я знаю почти никак. вобщем расскажи куда копать и я займусь этим аспектом.

>Должен тоже работать в принципе.

а как узнать точно? не хочу потратить время на поиски, а потом воткнуть его, увидеть что он неработает и нести его обратно, где его еще не факт что примут.

>> No.62132  
File: 1307795698781.png -(480081 B, 800x1000) Thumbnail displayed, click image for full size.
480081

>>62130

> блок питания это не единственное что может отказать

Блок питания и не единственное что резервируется в серверах.

> как правильнее всего диагностировать наличие/отсутствие соединений?
netstat -ntp
> а как узнать точно?

Воткнуть и проверить. Никто не дает гарантии что б/у проц вообще рабочим окажется или не откажет допустим при нагреве до 50 градусов. Попробуй договорится насчет тестового периода.

>> No.62133  

>>62132

>Блок питания и не единственное что резервируется в серверах.

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

>netstat -ntp

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

>Попробуй договорится насчет тестового периода.

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

>> No.62135  
File: 1307796436610.jpg -(144137 B, 1000x916) Thumbnail displayed, click image for full size.
144137

>>62133

> алсо что там резервируется кроме рэйда и питания?

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

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

Неисправный проц например ты теоретическим путем не обнаружишь.

>> No.62136  

>>62135

>Неисправный проц например ты теоретическим путем не обнаружишь

намного более вероятно что он просто не подойдет

>> No.62164  
File: 1307808043598.jpg -(432839 B, 996x1454) Thumbnail displayed, click image for full size.
432839

слежу вот так watch -n 0.1 'netstat -ntp | grep apache2'
наглядно получается

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

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

такая гипотеза

но как это связано с десятками форков жруших проц?

соберу еще инфы - расскажу.

>> No.62165  
File: 1307810757907.jpg -(95890 B, 750x562) Thumbnail displayed, click image for full size.
95890

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

также замечено, что отстрел этих процессов посредством kill -9 не приводит не к чему, они появляются снова, помогает только рестарт апача как сервиса.

>> No.62166  
File: 1307811874715.png -(3879399 B, 1750x2348) Thumbnail displayed, click image for full size.
3879399

>>62164

> но как это связано с десятками форков жруших проц?

Некорректно захлопнулось соединение и твой апач ожидает подтверждения о закрытии этого самого соединения. Возможно что тебя целенаправленно ддосят таким способом. Должно лечится увеличением лимита или же втыканием в промежуток между апачем и пользователями nginx или squid.

>> No.62168  
File: 1307814624742.jpg -(78540 B, 499x700) Thumbnail displayed, click image for full size.
78540

>>62166

>твой апач ожидает подтверждения о закрытии этого самого соединения

похоже на то! но зачем ему в этом состоянии жрать проц? причем это происходит независимо от виртуалхоста, так что на кривой пхп код списать не получается.

>Возможно что тебя целенаправленно ддосят таким способом.

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

>увеличением лимита

всмысле уменьшением таймаута подтверждения закрытия соединения?

>nginx или squid

а это чтобы оно не жрало проц и память пока будет ждать закрытия соединения?

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

>> No.62172  
File: 1307818300040.jpg -(343185 B, 1020x700) Thumbnail displayed, click image for full size.
343185

>>62168

> но зачем ему в этом состоянии жрать проц?

1% это не нагрузка.

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

По тем же логам/нетстату видно же.

> самого себя так подосить и смоделировать ситуацию

httperf+дроп FIN/RST например.

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

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

> а это чтобы оно не жрало проц и память пока будет ждать закрытия соединения?

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

> а где вообще можно толком почитать про этапы установки и закрытия соединения?

http://ru.wikipedia.org/wiki/TCP например.

>> No.62702  

>>62172
хм. вернемся к теме. мне тут человек посоветовал либо отключить трекинг соединений, либо существенно уменьшить /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_close_wait

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

у меня например джаббер там еще висит, а еще через это дело я в инет хожу, там у меня NAT.

>> No.62703  
>1% это не нагрузка.

это все что есть, учитывая что процессов порядка 100

>> No.62704  
File: 1308343070179.jpg -(110524 B, 648x486) Thumbnail displayed, click image for full size.
110524
>Думаю плохая идея, если ты заставишь систему рвать tcp после пары минут простоя то у тебя много чего полезного может начать отваливаться.

я почитал про TCP, подумал и пришел к выводу, что рваться ничего не будет, потому что ESTABLISHED и CLOSE_WAIT - это совсем разные вещи. в принципе второе состояние может вообще ничего не ждать и сразу сбрасывать соединение или я очень не прав?

>> No.62705  
File: 1308344180136.jpg -(67926 B, 555x429) Thumbnail displayed, click image for full size.
67926

мне вот что показалось подозрительным: в нетстате то со статусом CLOSE_WAIT висят воркеры юзерские, а не мультиплексоры. как вообще технически общаются воркеры с мультиплексорами? тоже через TCP? вполне может оказаться, что это вовсе и не DoS никакой, а несогласованная работа элементов внутри самой системы.

>> No.62707  
File: 1308344550409.png -(301488 B, 658x736) Thumbnail displayed, click image for full size.
301488

>>62702
Нетстатом отображаются локальные соединения а не обрабатываемые коннтраком, хотя последний отслеживает так же и локальные соединения. Если ты считаешь что коннтрак колбасит то можешь либо увеличить лимит вплоть до нескольких миллионов соединений, либо просто запретить трачить то, что идет к тебе на 80й порт или от тебя с 80го. Вот только на мой взгляд смысла в этом мало - ресурсы, потребляемые апачем на одно соединение во много раз больше чем ресурсы потребляемые контраком.
>>62703
Разных? Ставь проксик наизнанку с кешированием, посмотри что получится.
>>62704

> в принципе второе состояние может вообще ничего не ждать и сразу сбрасывать соединение или я очень не прав?

Плохая идея. Удаленная сторона вполне может еще что-то передавать/принимать в момент, когда соединение будет обрываться твоим сервером.

>> No.62708  
File: 1308344940608.jpg -(1354611 B, 1500x1500) Thumbnail displayed, click image for full size.
1354611

>>62705

> как вообще технически общаются воркеры с мультиплексорами? тоже через TCP?

Скорее всего fork()+setuid().

>> No.62711  
File: 1308346196522.jpg -(67395 B, 484x700) Thumbnail displayed, click image for full size.
67395

>>62707

>Нетстатом отображаются локальные соединения а не обрабатываемые коннтраком

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

>Разных? Ставь проксик наизнанку с кешированием, посмотри что получится.

PID'ы разные лол. юзеры чаще всего тоже.
а вообще с проксиком на изнанку это хороший вариант, но если уж применять такие серьезные решения, то есть вариант вообще использовать nginx в качестве мультиплексора, а апач для каждого вхоста свой на своем порту. но это серьезные меры, перед тем как к ним прибегать, хотелось бы исчерпать все в пределах существующего решения, потому как банально лень все это воротить. опять даунтаймы, еще неделя времени на fine tuning и не факт что поможет.

>Удаленная сторона вполне может еще что-то передавать/принимать в момент, когда соединение будет обрываться твоим сервером.

переход CLOSE_WAIT->LAST_ACK не является закрытием соединения, AFAIK. ESTABLISHED никто трогать не будет же.

>Скорее всего fork()+setuid().

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

>> No.62712  
File: 1308347608813.jpg -(1684454 B, 1600x1050) Thumbnail displayed, click image for full size.
1684454

>>62711

> коннтрак только следит и ничего не делает по части таймаутов

Но если ты выкрутишь таймаут коннтрака то у тебя начнут рваться по таймауту соединения через NAT.

> PID'ы разные лол. юзеры чаще всего тоже.

Текущий апач не трогай, просто перевесь его на 127.0.0.1 и левый порт, а проксику объясни чтобы он туда ходил как к parent proxy. Все это нужно, чтобы не держать чилдов в памяти пока клиент неспешно забирает уже сгенерированный контент.

> запрос так не передашь

Почему же? Принимаем соединение, форкамеся, получаем запрос, определяем пользователя по запросу, делаем setuid на него и обрабатываем.

> оно умеет держать постоянный пул

Возможно пайпы конечно, но это более сложно в реализации.

> так что форк там бывает далеко не на каждый запрос и даже не на каждый 10ый

Есть еще HTTP 1.1, где может быть куча запросов в пределах одного соединения.

>> No.62738  

>>62712

>Но если ты выкрутишь таймаут коннтрака то у тебя начнут рваться по таймауту соединения через NAT.

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

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

напомни, а почему у nginx не будет такой же проблемы как у апача? он сможет одним чайлдом держать много соединений?

>Почему же? Принимаем соединение, форкамеся,

не всегда форкаемся, вот, почитай:
http://www.peruser.org/trac/peruser/wiki/PeruserUnderTheHood
но там довольно поверхностно, про механизм передачи запроса не написано. тем не менее воркеры висят в нетстате так, как будто запросы передаются через сетевые сокеты.

>Есть еще HTTP 1.1, где может быть куча запросов в пределах одного соединения.

нет, это не тот случай, у меня явно выключен KeepAlive, поскольку его поддержка появилась относительно недавно в этом mpm и пока вроде как не рекомендуется им пользоваться.

>> No.62740  
File: 1308393615405.png -(1821635 B, 2000x2000) Thumbnail displayed, click image for full size.
1821635

>>62738

> напомни, а почему у nginx не будет такой же проблемы как у апача? он сможет одним чайлдом держать много соединений?

Да, он epoll использует для обработки сокетов. Так же как и squid (если конечно не брать в расчет его совсем древние версии).

>> No.62743  

>>62740

>он epoll использует для обработки сокетов

а в чем суть?

алсо я кажется наврал, там мультиплексоры висят с CLOSE_WAIT. сейчас еще помониторю.

>> No.62744  
File: 1308395873174.jpg -(79701 B, 700x525) Thumbnail displayed, click image for full size.
79701

>>62743

> а в чем суть?

Массовая обработка сокетов на уровне ядра практически без затрат ресурсов.
Так же думаю будет интересно почитать: http://groups.google.com/group/fido7.ru.unix.prog/browse_thread/thread/c7dbf41f7f1814f7

>> No.62749  

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

пока подрезал net.netfilter.nf_conntrack_tcp_timeout_close_wait до 5 секунд, смотрю что получится.

>> No.63816  
File: 1309466898535.png -(142398 B, 800x600) Thumbnail displayed, click image for full size.
142398

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

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

бюджет я пока точно незнаю какой будет, посмотрим. пока давай порассуждаем абстрактно, но начнем снизу.

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

или может лучше вообще забыть про х86 как про страшный сон и смотреть в прекрасное будщее выбирая ARM или MIPS? очень большое значение имеет потребление электроэнергии.

>> No.63824  
File: 1309470816152.jpg -(658632 B, 1600x1600) Thumbnail displayed, click image for full size.
658632

>>63816

> в связи с этим вопрос - а что бы мне за эти деньги купить? посоветуй какре-нибудь х86 решение с хорошими соотношениями производительность/цена и надежность/цена. или может даже не x86.

Все зависит от суммы. Если денег мало - бери десктоп, если много - бери сервак.

>> No.63840  
File: 1309498019237.jpg -(424751 B, 630x700) Thumbnail displayed, click image for full size.
424751

>>63816>>63824
guys, guys, hey guys, hey listen, hey guys, listen guys
сервак на gpu
?

>> No.63846  
File: 1309514058715.jpg -(486268 B, 850x741) Thumbnail displayed, click image for full size.
486268

>>63840
Наиболее медленные операции ввода-вывода и обращения к сетевым устройствам. На gpu ты их в любом случае не переложишь, а к тому, что можно переложить добавятся операции ввода-вывода из видеопамяти в оперативку. Так как gpu не умеет асинхронные запросы, все эти операции будут сопряжены с дополнительным ожиданием мьютексов. GPU выигрывает только на больших количествах (порядка миллионов) независимых однотипных вычислений.



Delete Post []
Password

[/b/] [/d/] [/tu/] [/a/] [/34/] [/ph/] [/wa/] [/cg/] [/t/]