> но разве это не лечится правильным кодом, особенно когда сервер занимается вычислением однотипных задач, как например в банковской сфере?
Там идет обслуживание транзакций, в какие-то моменты количество транзакций может быть пиковым, что вызовет значительные задержки, что вызовет создание очереди выполнения всех поступающих после.
Ближайший аналог — работа апача, только апач параллелится, а в банке всем необходимо работать с одной базой.
> Во-первых, если нет связи, никакой сигнал быть посланным не может быть по определению.
> Во-вторых, проверка канала связи, в зависимости от количества абонентов, может проходить раз или два в сутки. Ибо проверка идет
> последовательно. Это про «стандартных от МВД тревожный сигнал».
Ерунда какая-то. Я сам случайно отрывал телефонную пару идущую в квартиру, при стоящией стандартной мвд-шной сигналке — наряд сразу приезжает. Т.е. как только на телефонной паре, вместо коробки сигнализации получается обрыв (даже не в режиме работы) — тут же идет вызов.
Это особенность x86 архитектуры а не CPU.
При большой нагрузке (в unix-like осях, когда load average поднимается до 20-40 и более) производительность x86 начинает резко падать, практически эспоненциально, в то время, как на risk-архитектуре хоть и замедляется, но не сильно.
Скажем load average 60 в linux на x86 — это жестокий фриз, когда между набором даже простейшей команды типа «echo» и ее выполнением проходят десятки секунд, если не минуты, то с точно таким же load average на solaris запущенный на sparc t2000 — система оставалась отзывчивой, пользователи даже не сразу замечали, что что-то вообще не так.
> если бы на домашних тачках такое происходило, наверняка бы трубили об этом.
Ну, те, кто сталкивался — трубят. :)
> Или фильм ты пережимаешь, у тебя estimated 1:00
Пережатие фильма это один поток, он создаст load average = 1. Речь идет о случае, когда количество задач в очереди гораздо больше, чем успевает обрабатывать процессор.
Не так много именитых брендов. А так новые механические выходят буквально каждый месяц, на всяких групповых закупках постоянно собирают на разнообразные новинки народ, не говоря уж о самоделках, которые тоже вышли на мелкооптовые рубежи.
В общем, если следить, то движуха идет постоянно, то кто-то тюненные варианты кнопок выпустит, то другой для них демфирующие колпачки продает, третий пустые платы и корпуса, пятый — крышки клавиш из любого пластика.
"Мне нужно поговорить, а слушать меня некому. Я не могу говорить со стенами, они кричат на меня. Я не могу говорить с женой, она слушает только стены." Рей Бредбери "451 по Фаренгейту".
Давно хотел спросить, да все руки не доходили.
Как на счет КЛЛ? У меня довольно положительный опыт использования КЛЛ, наверно уже лет 8 я покупаю только их, в работе с пару десятков, заменяю по 3-5 в год, т.е. в среднем каждая лампа горит года 3.
При этом дают довольно хороший поток света, температуру можно подобрать, мерцания не видно, спектр вроде как довольно ровный. В общем все те детские проблемы светодиодных ламп меня не касаются. Пробовал несколько раз брать недорогие светодиодные, но в сравнении они оказались заметно хуже (правда брал просто что под руку подвернется в большом магазине), плюс менее чем за год все вышли из строя.
По этому я заинтересован в тестах КЛЛ, что бы выбрать самое надежное и с меньшими недостатками.
M-series странные. Мало кому нужны 1 CPU ноды с 32гб. Плюс этот шаред рейд из ссд, один на все картриджи.
Если b-series мы берем пачками под виртуализацию, то m-series купили всего пару шасси и пока так и не использовали толком. Разве что наоборот, переносить старые 1u сервера, которые по каким-то причинам нельзя виртуализовать (например жесткие требования по latency).
Мне кажется это слив. Никакой технической информации, как в статье, так и в комментариях, один маркентинговый булшит.
Тот же нетап рассказывает нам в десять раз больше, по этому нетап мы берем пачками. Ради чего брать 3пар не видно.
Скорее всего залогом успеха является хороший сервисный контракт. Если у вас контракт «Proactive 24» или «Critical Service», у которых поддержка «24х7, 4h response» то в 100% случаев ты будешь говорить с самим HP.
По дисковым массивам я знаю, что у них стояли локально Eva и XP, так что они могли применить твою рабочую конфигурацию у себя и имитировать разные варианты решения проблемм в песочнице.
Потому, что оригинальная игра была написана именно на Амиге (так же как Worms, и многие другие известные игры 80-х и 90-ых), а уже позже портировалась на PC и некоторые другие платформы.
Есть компании, которые делают схд на базе zfs и осуществляют коммерческую поддержку.
Да, фич а-ля кластеризации нескольких сторов тут нет, но они нужны далеко не всем. Нам хватает банальной двухголовости, данные между разными сторами ездят редко и делаются средствами vsphere.
Ага, сегодня смотрел презентацию с московского представления нетапа, что было пару недель как.
Наконец в 8.3.1 анонсировали онлайн компрессию и дедуп не убивающие проц хранилки.
То, чем уже лет пять(?) я пользуюсь на ZFS сторах.
Там идет обслуживание транзакций, в какие-то моменты количество транзакций может быть пиковым, что вызовет значительные задержки, что вызовет создание очереди выполнения всех поступающих после.
Ближайший аналог — работа апача, только апач параллелится, а в банке всем необходимо работать с одной базой.
> Во-вторых, проверка канала связи, в зависимости от количества абонентов, может проходить раз или два в сутки. Ибо проверка идет
> последовательно. Это про «стандартных от МВД тревожный сигнал».
Ерунда какая-то. Я сам случайно отрывал телефонную пару идущую в квартиру, при стоящией стандартной мвд-шной сигналке — наряд сразу приезжает. Т.е. как только на телефонной паре, вместо коробки сигнализации получается обрыв (даже не в режиме работы) — тут же идет вызов.
При большой нагрузке (в unix-like осях, когда load average поднимается до 20-40 и более) производительность x86 начинает резко падать, практически эспоненциально, в то время, как на risk-архитектуре хоть и замедляется, но не сильно.
Скажем load average 60 в linux на x86 — это жестокий фриз, когда между набором даже простейшей команды типа «echo» и ее выполнением проходят десятки секунд, если не минуты, то с точно таким же load average на solaris запущенный на sparc t2000 — система оставалась отзывчивой, пользователи даже не сразу замечали, что что-то вообще не так.
> если бы на домашних тачках такое происходило, наверняка бы трубили об этом.
Ну, те, кто сталкивался — трубят. :)
> Или фильм ты пережимаешь, у тебя estimated 1:00
Пережатие фильма это один поток, он создаст load average = 1. Речь идет о случае, когда количество задач в очереди гораздо больше, чем успевает обрабатывать процессор.
В общем, если следить, то движуха идет постоянно, то кто-то тюненные варианты кнопок выпустит, то другой для них демфирующие колпачки продает, третий пустые платы и корпуса, пятый — крышки клавиш из любого пластика.
Как на счет КЛЛ? У меня довольно положительный опыт использования КЛЛ, наверно уже лет 8 я покупаю только их, в работе с пару десятков, заменяю по 3-5 в год, т.е. в среднем каждая лампа горит года 3.
При этом дают довольно хороший поток света, температуру можно подобрать, мерцания не видно, спектр вроде как довольно ровный. В общем все те детские проблемы светодиодных ламп меня не касаются. Пробовал несколько раз брать недорогие светодиодные, но в сравнении они оказались заметно хуже (правда брал просто что под руку подвернется в большом магазине), плюс менее чем за год все вышли из строя.
По этому я заинтересован в тестах КЛЛ, что бы выбрать самое надежное и с меньшими недостатками.
Если b-series мы берем пачками под виртуализацию, то m-series купили всего пару шасси и пока так и не использовали толком. Разве что наоборот, переносить старые 1u сервера, которые по каким-то причинам нельзя виртуализовать (например жесткие требования по latency).
Тот же нетап рассказывает нам в десять раз больше, по этому нетап мы берем пачками. Ради чего брать 3пар не видно.
По дисковым массивам я знаю, что у них стояли локально Eva и XP, так что они могли применить твою рабочую конфигурацию у себя и имитировать разные варианты решения проблемм в песочнице.
Да, фич а-ля кластеризации нескольких сторов тут нет, но они нужны далеко не всем. Нам хватает банальной двухголовости, данные между разными сторами ездят редко и делаются средствами vsphere.
Наконец в 8.3.1 анонсировали онлайн компрессию и дедуп не убивающие проц хранилки.
То, чем уже лет пять(?) я пользуюсь на ZFS сторах.