Рассчитано это на разработчиков, у них есть доступ в интернет. Это не потребительский телефон.
Очевидно, что Google может сделать супер телефон, но это же убьёт его отношения с производителями, это будет уже Apple какой-то. IMHO Google старается делать несколько ущербную (нет карточки, встроенный аккумулятор) модель обвешанную всеми возможными датчиками (та же зарядка беспроводная) у разных производителей (HTC, Samsung, LG).
Рекламы у Nexus'а тоже не очень много.
В итоге разработчики могут обкатать разные плюшки и написать программы/плагины/виджеты для любого «прибамбаса» (например, включения офисного режима, когда телефон оказывается на беспроводной зарядке в будний день).
Производители телефонов налаживают отношения с Google.
Для старенького Galaxy S (i9100) на стоковой прошивке помогло установить Dialer One и теперь система спрашивает чем звонить. При просмотре страницы это настораживает и позволяет не попадаться.
А вообще да, бяка страшная и не понятно как будут латать старые модели
Там есть несколько вариантов:
1. Втыкают растворимый (водо-растворимый) пластик. Напечатал, отмочил и крути.
2. Масса порошка (очень тонкого порошка), который подсыпают и поливают клеем. Надо будет вытрясти порошок из соединений
3. Тонкие подпорки из основного материала, который потом ломаются.
Есть проблема не только тепла, но и размера. Скорость света в ваккуме 300_000_000 м/с, скорость света в меди 200_000_000 м/с. То есть на 2GHz за 1 такт ток протечёт только 10 см. А если 4 GHz, то всего 5.
При том, что надо бы несколько транзисторов использовать за такт.
То есть мы просто не успеем бегать по большому кристаллу и не дотянемся до дальних транзисторов.
Если нужен «большой процессор», ставьте 2 рядом, или 200. Только разговаривать они между собой будут на низких скоростях.
Интересно, а как они с утечкой гелия собираются бороться?
И можно ли будет перевозить эти диски в самолёте, там же давление пониже будет, не разорвёт ли винт?
Надо 500 суток лететь туда-обратно. Всё это время космическая радиация будет жарить, где-то читал, что чтобы заменить атмосферу и магнитное поле земли надо стенку из железа всего 2,5 метра толщиной.
То есть люди будут лететь и просвещаться.
Ну и людей надо назад везти, в отличии от роверов.
Получается очень дорого и не понятно зачем. Роботы развиваются очень быстро и массу задач можно будет решить ими, а не людьми.
Мне показалось, что в aio будет проблема с сигналами, так как сообщения от ядра идут именно через сигналы. Не много ли вызовов будет?
Грубо, на один вызов select/poll/epoll мы можем получить сотню дескрипторов и их обработать. В случае aio это будет сотня сигналов.
Более того, мы в сигнале не можем особенно делать системные вызовы, поэтому мы всё равно сделаем свою очередь, которую будем пополнять в обработчике сигналов, а читать в общем цикле.
В aio круто то, что можно послать большой буфер в fd одним вызовом, но мы упираемся в память сервера на 10k больших буферов. Если же шлём контент из файла, то sendfile ничем не хуже.
Если бы не сигналы, а возможность выгребать события из очереди…
rrdcached выглядит каким-то половинчатым.
Он аккумулирует данные, но не даёт прочитать их из кеша. Только записать на диск. То есть если надо работать с данными, например посчитать агрегат или ещё чего, то есть записываем на диск и читаем с диска.
Плюс он сам пишет на диск в непредсказуемый момент.
Проблема в том, что никто не будет смотреть на 1000 графиков разом. У нас есть скрипты, которые собирают данные в несколько небольших dashboard и они читают много rrd'шек, сильно больше 1000. То есть кеш на ключевых метриках работать не будет и винт будет грузиться
Да, большинство метрик не жалко вообще стереть, но и на них кеш будет переполняться и грузить винт и не давать работать ключевым метрикам.
Я вообще сомневаюсь, что кеш будет хорошо работать в случае одновременного апдейта всех rrd раз в 5 минут.
Идея то в чём, в том, что с точки зрения диска что записать одно измерение, что 20 одинаково трудоёмко, считать файл с диска и записать на диск.
То есть надо держать в памяти по несколько измерений каждой метрики, плюс некая служебная информация (которая в нашем мире динамической памяти часто очень большая). При этом надо постоянно обращаться к кешу при каждом чтении/записи, что тоже нагрузка на процессор.
Почему бы не положить всё в память и работать с памятью? Особенно если оно туда влазит. Быстрее же будет и заметно проще.
А оно влазит! Память стоит всё дешевле и дешевле, причём закон Мура тут ещё будет долго работать, в отличии от процессоров.
В Munin не очень круто то, что метрики только раз в 5 минут и это врождённое, это не обойти. Иногда хочется чаще, но никак.
Мы даже думали другой мониторинг (тот же Zabbix) на небольшое количество метрик поставить с большей частотой.
«сбор практически всех метрик настраивается через веб-морду»
В нашем случае это не совсем фича.
Грубо, разработчик может захотеть метрику. Он её просто делает как плагин в новой версии роли и всё. Новая версия ставится, метрика появляется. Причём если версия ставится в Live Test, на один сервер, то и появляется на одном.
В Zabbix он бы ещё и просил кого-то с админскими правами (или опытом) добавить новый шаблон с новой метрикой.
Если разработчик накосячил в плагине на сервере, то поправит в следующей вертике и научится на горьком опыте. Мучать центральную конфигурацию и учиться ему никто не даст.
Так же у нас есть централизованная база с конфигурацией системы, из неё надо делать все конфиги. И тут текстовые конфиги Munin (сгенерировал с нуля, подложил) удобнее чем любое API. Например, выявлять и удалять исчезнувшие ноды надо.
Ох ты жеж. Чего же вы шлёте раз в секунду или раз в 5 секунд?
Супер полезная информация, если сервер умрёт, но это же нагрузка не только на мастер, но и на ноду
А как часто у вас собираются данные с метрик? Грубо, сколько метрик в секунду снимается?
Потому что 50k раз в секунду это очень круто, а раз в 5 минут — у нас 275k тянет спокойно.
А как часто обновляются данные? В среднем, конечно.
У нас 1600 нод, которые мониторятся (это и сервера и виртуальные контейнеры на них).
275000 метрик (линий на графиках).
Получается на порядок больше «хостов», в 2 раза меньше данных (14 против 32GB).
Или вы чаще собираете, или дольше храните. Munin собирает раз в 5 минут.
С Zabbix нормально не работал, но очевидные различия:
— База против rrd, вытянет ли база на наших объёмах? (rrd не тянет, пришлось в память положить)
— Централизованная конфигурация (Zabbix) против децентрализованной (Munin).
У нас разные команды админов и разработчиков. В случае Munin разработчик приделывает график сам (добавляет плагин) и никого не ждёт. В Zabbix он должен просить кого-то с админскими правами. Новый график может появится на Dev/LiveTest сервере, а на основной массе его не будет. И именно этот график хорошо показывает как оно работает новая версия.
В централизованной системе (Zabbix) это сложнее сделать. Эта фича не бесплатна, конфиг Munin раздувается страшно. Но оно стоит того (в наших условиях)
Ну и главное. У нас были Munin+Nagios, мы их настроили, мы к ним привыкли, мы их знаем. Zabbix это сильно новое. «работает — не трожь!»
PS Zabbix красив, конечно. Пробуем его но пока в проде стоит Munin
Очевидно, что Google может сделать супер телефон, но это же убьёт его отношения с производителями, это будет уже Apple какой-то. IMHO Google старается делать несколько ущербную (нет карточки, встроенный аккумулятор) модель обвешанную всеми возможными датчиками (та же зарядка беспроводная) у разных производителей (HTC, Samsung, LG).
Рекламы у Nexus'а тоже не очень много.
В итоге разработчики могут обкатать разные плюшки и написать программы/плагины/виджеты для любого «прибамбаса» (например, включения офисного режима, когда телефон оказывается на беспроводной зарядке в будний день).
Производители телефонов налаживают отношения с Google.
А простые люди будут покупать SGS III
А вообще да, бяка страшная и не понятно как будут латать старые модели
Наверное ультразвуковые ванночки помогут. Моют же печатные платы от флюса, в том числе и места под элементами.
Вот чего нашёл www.youtube.com/watch?v=MQtedzkmKlQ (модель двигателя, одним куском)
Говорит печатал 28 часов и 2 дня отмачивал.
Но это не Кубик Рубика, кубик надо будет дольше отмачивать.
1. Втыкают растворимый (водо-растворимый) пластик. Напечатал, отмочил и крути.
2. Масса порошка (очень тонкого порошка), который подсыпают и поливают клеем. Надо будет вытрясти порошок из соединений
3. Тонкие подпорки из основного материала, который потом ломаются.
При том, что надо бы несколько транзисторов использовать за такт.
То есть мы просто не успеем бегать по большому кристаллу и не дотянемся до дальних транзисторов.
Если нужен «большой процессор», ставьте 2 рядом, или 200. Только разговаривать они между собой будут на низких скоростях.
И можно ли будет перевозить эти диски в самолёте, там же давление пониже будет, не разорвёт ли винт?
То есть люди будут лететь и просвещаться.
Ну и людей надо назад везти, в отличии от роверов.
Получается очень дорого и не понятно зачем. Роботы развиваются очень быстро и массу задач можно будет решить ими, а не людьми.
Фобос-Грунт 2 раза откладывали. Может стоило и 3-ий раз отложить.
Меня вот удивляют кабели из США в США, из Китая в Китай и т.д.
На суше же легче обслуживать, легче питать. Ладно если голый кабель лежит, но каждый ретранслятор это же проблема.
Грубо, на один вызов select/poll/epoll мы можем получить сотню дескрипторов и их обработать. В случае aio это будет сотня сигналов.
Более того, мы в сигнале не можем особенно делать системные вызовы, поэтому мы всё равно сделаем свою очередь, которую будем пополнять в обработчике сигналов, а читать в общем цикле.
В aio круто то, что можно послать большой буфер в fd одним вызовом, но мы упираемся в память сервера на 10k больших буферов. Если же шлём контент из файла, то sendfile ничем не хуже.
Если бы не сигналы, а возможность выгребать события из очереди…
Он аккумулирует данные, но не даёт прочитать их из кеша. Только записать на диск. То есть если надо работать с данными, например посчитать агрегат или ещё чего, то есть записываем на диск и читаем с диска.
Плюс он сам пишет на диск в непредсказуемый момент.
Проблема в том, что никто не будет смотреть на 1000 графиков разом. У нас есть скрипты, которые собирают данные в несколько небольших dashboard и они читают много rrd'шек, сильно больше 1000. То есть кеш на ключевых метриках работать не будет и винт будет грузиться
Да, большинство метрик не жалко вообще стереть, но и на них кеш будет переполняться и грузить винт и не давать работать ключевым метрикам.
Я вообще сомневаюсь, что кеш будет хорошо работать в случае одновременного апдейта всех rrd раз в 5 минут.
Идея то в чём, в том, что с точки зрения диска что записать одно измерение, что 20 одинаково трудоёмко, считать файл с диска и записать на диск.
То есть надо держать в памяти по несколько измерений каждой метрики, плюс некая служебная информация (которая в нашем мире динамической памяти часто очень большая). При этом надо постоянно обращаться к кешу при каждом чтении/записи, что тоже нагрузка на процессор.
Почему бы не положить всё в память и работать с памятью? Особенно если оно туда влазит. Быстрее же будет и заметно проще.
А оно влазит! Память стоит всё дешевле и дешевле, причём закон Мура тут ещё будет долго работать, в отличии от процессоров.
Мы даже думали другой мониторинг (тот же Zabbix) на небольшое количество метрик поставить с большей частотой.
В нашем случае это не совсем фича.
Грубо, разработчик может захотеть метрику. Он её просто делает как плагин в новой версии роли и всё. Новая версия ставится, метрика появляется. Причём если версия ставится в Live Test, на один сервер, то и появляется на одном.
В Zabbix он бы ещё и просил кого-то с админскими правами (или опытом) добавить новый шаблон с новой метрикой.
Если разработчик накосячил в плагине на сервере, то поправит в следующей вертике и научится на горьком опыте. Мучать центральную конфигурацию и учиться ему никто не даст.
Так же у нас есть централизованная база с конфигурацией системы, из неё надо делать все конфиги. И тут текстовые конфиги Munin (сгенерировал с нуля, подложил) удобнее чем любое API. Например, выявлять и удалять исчезнувшие ноды надо.
Супер полезная информация, если сервер умрёт, но это же нагрузка не только на мастер, но и на ноду
Потому что 50k раз в секунду это очень круто, а раз в 5 минут — у нас 275k тянет спокойно.
У нас 1600 нод, которые мониторятся (это и сервера и виртуальные контейнеры на них).
275000 метрик (линий на графиках).
Получается на порядок больше «хостов», в 2 раза меньше данных (14 против 32GB).
Или вы чаще собираете, или дольше храните. Munin собирает раз в 5 минут.
— База против rrd, вытянет ли база на наших объёмах? (rrd не тянет, пришлось в память положить)
— Централизованная конфигурация (Zabbix) против децентрализованной (Munin).
У нас разные команды админов и разработчиков. В случае Munin разработчик приделывает график сам (добавляет плагин) и никого не ждёт. В Zabbix он должен просить кого-то с админскими правами. Новый график может появится на Dev/LiveTest сервере, а на основной массе его не будет. И именно этот график хорошо показывает как оно работает новая версия.
В централизованной системе (Zabbix) это сложнее сделать. Эта фича не бесплатна, конфиг Munin раздувается страшно. Но оно стоит того (в наших условиях)
Ну и главное. У нас были Munin+Nagios, мы их настроили, мы к ним привыкли, мы их знаем. Zabbix это сильно новое. «работает — не трожь!»
PS Zabbix красив, конечно. Пробуем его но пока в проде стоит Munin