http://freesource.info/wiki/DenisSmirnov/ВыборОборудования History/revisions of FreeSource/DenisSmirnov/ВыборОборудования en-us http://freesource.info/wiki/DenisSmirnov/VyborOborudovanija/show?time=2005-04-06+17%3A44%3A24 <div class="pageBefore"><img src="http://freesource.info/wiki/images/z.gif" width="1" height="1" border="0" alt="" style="display:block" align="top" /></div><div class="page"> <b>Сравнение версий <a name=".denissmirnov.vyboroborudovanija" href="http://freesource.info/wiki/DenisSmirnov/VyborOborudovanija&" class="">/Denis&nbsp;Smirnov&nbsp;/&nbsp;Выбор&nbsp;Оборудования</a> за <a href="http://freesource.info/wiki/DenisSmirnov/VyborOborudovanija?time=2005-04-06+17%3A44%3A24">2005-04-06 17:44:24</a> и <a href="http://freesource.info/wiki/DenisSmirnov/VyborOborudovanija">2005-04-06 17:45:35</a></b><br /> <br /> <b>Добавлено:</b><br /> <div class="additions">Выбор железа это&nbsp;исключительно выбор финансовый. Если тебе говорят &laquo;у нас&nbsp;бюджет 1k$, делай файлсервер&raquo;, то&nbsp;никуда не&nbsp;денешься &mdash; будешь монстрить RAID на&nbsp;SATA-дисках.<br /> Открою большую тайну &mdash; задачи они, знаете ли, разные бывают. Вот&nbsp;на&nbsp;download.seiros.ru трудятся 2 SATA-диска. Нормальненько так&nbsp;себе трудятся. По&nbsp;крайней мере сервер работает шустро, несмотря на&nbsp;то, что&nbsp;там hasher круглосуточно пакеты пересобирает. Под&nbsp;athlon. И&nbsp;если мне&nbsp;кто-то скажет что&nbsp;я&nbsp;должен туда ставить SCSI-диски, я&nbsp;ему в&nbsp;лицо скажу что&nbsp;он&nbsp;идиот, ибо&nbsp;на&nbsp;имеющейся нагрузке справляется имеющееся железо. А&nbsp;SCSI-диски того же&nbsp;объёма были бы&nbsp;слишком дороги для&nbsp;меня (читай &mdash; этого проекта просто не&nbsp;было бы, вообще).<br /> Любая серьёзная задача, а&nbsp;настройка сервера относится к&nbsp;таковым, решается обычно комплексно. Редко удаётся сделать всё из&nbsp;&laquo;идеальных&raquo; компонент &mdash; то&nbsp;чем мы&nbsp;пользуемся это&nbsp;&laquo;стройная система костылей и&nbsp;подпорок&raquo;. Ублюдочная архитектура x86, с&nbsp;кучей левых &laquo;доделок&raquo; (я про&nbsp;разные MMX, SSE, x86_64). Ядро с&nbsp;кривой архитектурой, которая имеет море недостатоков, набор библиотек часто с&nbsp;кретиническими ошибками, ублюдочный язык программирования (язык программирования в&nbsp;котором изначально нет&nbsp;понятия &laquo;строка&raquo;, при&nbsp;том что&nbsp;оно нужно очень часто породил множество видов уязвимостей, невозможных для&nbsp;нормальных языков), приложения с&nbsp;дебильнейшей архитектурой в&nbsp;плане безопасности (bind напрмер. в&nbsp;котором чуть ли&nbsp;не каждый день находят ворох ошибок).<br /> Задача любого разрабочика или&nbsp;админа &mdash; из&nbsp;всего этого, откровенного говоря, [censored], сделать надёжную, удобную и&nbsp;функциональную систему для&nbsp;пользователя, в&nbsp;условиях когда это&nbsp;пользователь не&nbsp;готов тех&nbsp;денег, которые это&nbsp;стоит (а в&nbsp;России почти всегда так).<br /> Поэтому на&nbsp;нескольких разных уровнях построения системы делается всё возможное, чтобы обеспечить приемлимую производительность и&nbsp;надёжность.<br /> Помнится в&nbsp;прошлом году Михаил Шигорин писал, как&nbsp;красиво одна система умирала на&nbsp;ext3 под&nbsp;нагрузкой (не умеет нормально работать с&nbsp;несколькими параллельными потоками чтения/записи больших файлов), и&nbsp;как она&nbsp;полетела от&nbsp;простой замены fs&nbsp;на xfs.<br /> Спор &laquo;какая FS&nbsp;<u>лучшая</u>&raquo; &mdash; бессмысленен. Имеет смысл только &laquo;какая FS, в&nbsp;какой ситуации, какие преимущества имеет?&raquo;.<br /> <!--notypo-->{{backlinks}}<!--/notypo--></div><br /> <b>Удалено:</b><br /> <div class="deletions">Выбор железа это&nbsp;исключительно выбор финансовый. Если тебе говорят &laquo;у нас<br /> бюджет 1k$, делай файлсервер&raquo;, то&nbsp;никуда не&nbsp;денешься &mdash; будешь монстрить RAID<br /> на&nbsp;SATA-дисках.<br /> Открою большую тайну &mdash; задачи они, знаете ли, разные бывают. Вот&nbsp;на<br /> download.seiros.ru трудятся 2 SATA-диска. Нормальненько так&nbsp;себе трудятся. По<br /> крайней мере сервер работает шустро, несмотря на&nbsp;то, что&nbsp;там hasher<br /> круглосуточно пакеты пересобирает. Под&nbsp;athlon. И&nbsp;если мне&nbsp;кто-то скажет что&nbsp;я<br /> должен туда ставить SCSI-диски, я&nbsp;ему в&nbsp;лицо скажу что&nbsp;он&nbsp;идиот, ибо&nbsp;на<br /> имеющейся нагрузке справляется имеющееся железо. А&nbsp;SCSI-диски того же&nbsp;объёма<br /> были бы&nbsp;слишком дороги для&nbsp;меня (читай &mdash; этого проекта просто не&nbsp;было бы,<br /> вообще).<br /> Любая серьёзная задача, а&nbsp;настройка сервера относится к&nbsp;таковым, решается<br /> обычно комплексно. Редко удаётся сделать всё из&nbsp;&laquo;идеальных&raquo; компонент &mdash; то&nbsp;чем<br /> мы&nbsp;пользуемся это&nbsp;&laquo;стройная система костылей и&nbsp;подпорок&raquo;. Ублюдочная<br /> архитектура x86, с&nbsp;кучей левых &laquo;доделок&raquo; (я про&nbsp;разные MMX, SSE, x86_64). Ядро<br /> с&nbsp;кривой архитектурой, которая имеет море недостатоков, набор библиотек часто с<br /> кретиническими ошибками, ублюдочный язык программирования (язык<br /> программирования в&nbsp;котором изначально нет&nbsp;понятия &laquo;строка&raquo;, при&nbsp;том что&nbsp;оно<br /> нужно очень часто породил множество видов уязвимостей, невозможных для<br /> нормальных языков), приложения с&nbsp;дебильнейшей архитектурой в&nbsp;плане безопасности<br /> (bind напрмер. в&nbsp;котором чуть ли&nbsp;не каждый день находят ворох ошибок).<br /> Задача любого разрабочика или&nbsp;админа &mdash; из&nbsp;всего этого, откровенного говоря,<br /> [censored], сделать надёжную, удобную и&nbsp;функциональную систему для<br /> пользователя, в&nbsp;условиях когда это&nbsp;пользователь не&nbsp;готов тех&nbsp;денег, которые это<br /> стоит (а в&nbsp;России почти всегда так).<br /> Поэтому на&nbsp;нескольких разных уровнях построения системы делается всё возможное,<br /> чтобы обеспечить приемлимую производительность и&nbsp;надёжность.<br /> Помнится в&nbsp;прошлом году Михаил Шигорин писал, как&nbsp;красиво одна система умирала<br /> на&nbsp;ext3 под&nbsp;нагрузкой (не умеет нормально работать с&nbsp;несколькими параллельными<br /> потоками чтения/записи больших файлов), и&nbsp;как она&nbsp;полетела от&nbsp;простой замены fs<br /> на&nbsp;xfs.<br /> Спор &laquo;какая FS&nbsp;_лучшая_" &mdash; бессмысленен. Имеет смысл только &laquo;какая FS, в&nbsp;какой<br /> ситуации, какие преимущества имеет?&raquo;.</div></div>