Почему же? До и После написания статьи две совершенно разные ситуации. Если До можно было делать вид, что о баге не было известно, то После продолжая работу в таком режиме обменники показывают, что их действия осмысленны и умышленны, а мониторинг в лице https://changeinfo.ru зная о баге соучаствует в процессе обмана не исключая их из рейтинга, да ещё и говоря "Все они заслуживают вашего полного доверия и проверены нашими менеджерами."
Даже когда в интерфейсе присутствовали рубли все операции происходили с конвертацией через гривну. Я об этом писал статью, но на хабре это запретная тема и за её обсуждение нещадно банят.
https://money.yandex.ru/embed/quickpay/shop.xml?from=iget&_openstat=iget%3Bshop%3Bicon
Кошельки на Яндексе:
— комиссия берется с получателя, 0,5% от суммы.
Банковские карты:
— комиссия берется с получателя, 2% от суммы.
Интеркасса пользует ликпей, т.е. конвертация всех платежей через гривну, как следствие клиент платит на 5-10% больше. Сейчас даже RUR отсутствует в интерфейсе карточных платежей.
«зачем доверять production сервер» фигулинке под usb?
Не только под usb. Те самые перезагрузки постом выше вызваны устройством включенным в LPT, но при этом забыли учесть в какое состояние переходит lpt при перезагрузке. В итоге рекурсивно перезагружали сами себя.
Бывает и часто. У нас был случай(именно по этому реле) когда из-за программной ошибки оно должно было сработать около 5000 раз за 16 дней (попало на праздники и не могли попасть в помещение где стояла станция). Но, судя по логам, перезагрузки прекратились (контакты залипли) на ~1500 сработках. При этом по заявлению производителя цифры сработок даже не в 5-м порядке.
Я не обощаю — старые добрые РЭС-9 работали по 30 лет и более. Да и у меня в 97 году в обслуживании была координатка выпуска 62-го, а там все контакты «на воздухе». Т.е. не все ЭМР «шлак», но зачем доверять production сервер устройству зависящему от натяжения струн/материалу площадок, если альтернатива на доллар/два дороже?
На самом деле даже бренды типа kramer и сейчас используют электромеханические реле, но это скорее дань долгосрочным договорным обязательствам. Исключением могут служить ртутные герконы.
В остальном, если не крично сопротивление замкнутой контактами цепи, альтернативы твердотельным реле нет.
проблем 2:
— перегорание обмотки
— залипание контактов
Если первая проблема больше критична при перегрузках/ударах молнии, то вторая весьма актуальна для этих реле. С учётом того что контактная площадка не из благородных металлов и зазор очень мал залипание начинается уже при 1000 сработках. На вышеприведённом по ссылке ребутаторе мы использовали имено эти реле (серии IM). Через год 30% были залипшими. Перевод на твердотельные (того же axicom) решил проблему.
PS: с проблемой залипания контактов знаком не по наслышке и до того. 4 года отработал механиком на координатных АТСК 50/200. Даже серебрянные контакты и палладиевые струны «липнут» при дрожании/искрении.
Да дело даже не в 2А-ом токе. Доверять управление сервером электромеханической релюшке (включенной в другой сервер?) можно только если уж совсем ничего ценнго на управляемом сервере нет.
Сам использовал самопальный ребутатор, но он управлял тв-тюнерами бытового уровня для которых перезапуск по питанию только на пользу.
reboot использовать не кошерно, а надо использовать 'shutdown -r'
Это справедливо для FreeBSD, при неаварийной перезагрузке нужно использовать shutdown -r
При этом сначала быдет выполняться /etc/rc.shutdown для корректного завершения процессов.
При reboot просто всем пошлётся sigterm, подождёт (по дефолту вроде 30 сек), потом sigkill
сложилось мнение, что это один из самых распространённых вопросов на собеседованиях
Напомнили вопросы на одном из собеседований (лет 10 назад, компания сейчас с Громким именем):
1) кто автор утилиты traceroute?
2) почему Ван выбрал порт 33434 (и как его легко запомнить)?
Ответил на оба, но работать к ним не пошёл. Нахрена мне это знать как простому админу?
Утилита, которой можно указать порты TCP или UDP занимается tcptraceroute
Возможность выбора диапазона портов была в первой же версии traceroute, по крайней мере во FreeBSD 1.0 уже присутствовала. Вот выбор протоколов появился только с FreeBSD 4.0.
в то время как traceroute стандартная утлилита для любого unix-сервера
Да ладно Вам.
Простейшая трассировка: # traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
1 31.41.40.1 0.569 ms 0.476 ms 0.452 ms
2 10.52.12.1 0.463 ms 0.561 ms 0.514 ms
3 95.213.189.1 0.608 ms 0.549 ms 0.536 ms
4 195.208.208.232 1.539 ms 0.957 ms 1.587 ms
5 66.249.94.100 2.137 ms
66.249.94.94 2.101 ms 1.619 ms
6 66.249.95.241 25.756 ms
64.233.174.85 25.829 ms
209.85.243.149 22.934 ms
7 216.239.56.208 17.262 ms
216.239.40.240 16.171 ms
209.85.247.77 16.547 ms
8 * * *
9 8.8.8.8 14.459 ms 14.591 ms 13.890 ms
Откуда взялся серый адрес на втором хопе?
Почему на 5-6-7 ответы от нескольких ip?
Почему время ответов на 9-м шаге меньше чем на 6-м?
и т.д. и т.п.
О traceroute можно роман написать.
20 лет "публично" не переводил, да и сам англоязычный вариант тяжеловат. Он перенасыщен повторяющимися словами, и при переводе не удаётся подобрать "технические" синонимы. В первоначальном варианте хотел частично оставить pipe, redirect и т.п., но в итоге заменил таки, возможно зря. Можно было бы переписать свою статью, но это было бы нечестно по отношению к автору оригинала.
Если name является адресом IPv4 или IPv6, то поиск не производится и gethostbyname() просто копирует name в поле h_name, а его эквивалент для структуры struct in_addr копируется в поле h_addr_list[0] возвращаемой структуры hostent
так и при реальном разрешении имён, т.к. будет задействован механизм NSCD (если только не делать принудительный invalidate кеша).
А зачем?
С чем его сравнивать?
Говоря о UDP подразумевая SOCK_DGRAM, т.е. на доменах AF_UNIX/AF_INET имеем те же отличия что и при SOCK_STREAM.
Говоря о UDP подразумевая отличия в одном домене имён между SOCK_DGRAM и SOCK_STREAM имеем негарантированную доставку пакета ограниченного размера.
Не, вы уж извольте убрать gethostbyname в тесте TCP, а то нечестно как-то
1) Это как раз честно. Представьте socket-клиент в реальных условиях. Будет ли он без gethostbyname?
2) На самом деле вес gethostbyname в массе(да пусть поперхнутся физики) ничтожен. Даже на НЕ-локальных вызовах он окажет куда меньшее влияние чем может оказать, например, размер пакета.
Тут дело не в самих сокетах, а в том как с ними работает драйвер php и сам redis.
А что PHP или Redis используют некие несистемные средства работы с сокетами?
Листаю исходники redis. Как и ожидалось все функции anetTcp отличаются от anetUnix именно "добавлением" в Tcp-функциях getaddrinfo, bind, ntohs.
Чтение и запись реализованы в "общих" anetRead, anetWrite. И пока не могу полагать, что работа с сокетами одного типа может отличаться чем-то кроме дополнительных расходов на tcp-обработку.
Например также читал, что у редиса была (или еще есть?) бага, связанная с тем, что UDS не отвечает в момент записи редисом данных на диск, в то же время tcp просто ожидает ответа.
С чего вдруг?
Сокеты одного типа SOCK_STREAM. За исключением того, что в домене AF_INET мы несём накладные расходы на именование сокета, htonX'ы, муршрутизацию, asc'и принципиальных отличий от AF_UNIX нет. Как следствие, чем меньше длина пакета данных, тем больше будет выигрыш при использовании сокетов в домене файловой системы. Как правило, это порядка 50%.
Поэтому (если исключить правку кода для внедрения в редис IPS с использованием разделяемой памяти) AF_UNIX сокеты будут самыми производительными. А ввиду того, что read/write для них реализован одинаково сравнивать стабильность не приходится.
обрабатываем несколько тысяч запросов в секунду для получения статистики доставки и открытия уведомлений и для передачи контента оповещений. Обычная БД вроде MySQL не справляется с таким потоком запросов и не может так быстро отвечать.
Ни чистых Insert'ах отправлял в продакшине данные из nginx в MySQL порядка 30'000 qps и это был не предел. На чистой синтетике (в режиме храниения данных а-ля redis — ключ/значение) думаю можно добиться и более 100'000 qps.
Почему же? До и После написания статьи две совершенно разные ситуации. Если До можно было делать вид, что о баге не было известно, то После продолжая работу в таком режиме обменники показывают, что их действия осмысленны и умышленны, а мониторинг в лице https://changeinfo.ru зная о баге соучаствует в процессе обмана не исключая их из рейтинга, да ещё и говоря "Все они заслуживают вашего полного доверия и проверены нашими менеджерами."
Кошельки на Яндексе:
— комиссия берется с получателя, 0,5% от суммы.
Банковские карты:
— комиссия берется с получателя, 2% от суммы.
Не только под usb. Те самые перезагрузки постом выше вызваны устройством включенным в LPT, но при этом забыли учесть в какое состояние переходит lpt при перезагрузке. В итоге рекурсивно перезагружали сами себя.
Не обязательно. Зависит от бюджета и задачи.
Я не обощаю — старые добрые РЭС-9 работали по 30 лет и более. Да и у меня в 97 году в обслуживании была координатка выпуска 62-го, а там все контакты «на воздухе». Т.е. не все ЭМР «шлак», но зачем доверять production сервер устройству зависящему от натяжения струн/материалу площадок, если альтернатива на доллар/два дороже?
В остальном, если не крично сопротивление замкнутой контактами цепи, альтернативы твердотельным реле нет.
— перегорание обмотки
— залипание контактов
Если первая проблема больше критична при перегрузках/ударах молнии, то вторая весьма актуальна для этих реле. С учётом того что контактная площадка не из благородных металлов и зазор очень мал залипание начинается уже при 1000 сработках. На вышеприведённом по ссылке ребутаторе мы использовали имено эти реле (серии IM). Через год 30% были залипшими. Перевод на твердотельные (того же axicom) решил проблему.
PS: с проблемой залипания контактов знаком не по наслышке и до того. 4 года отработал механиком на координатных АТСК 50/200. Даже серебрянные контакты и палладиевые струны «липнут» при дрожании/искрении.
Сам использовал самопальный ребутатор, но он управлял тв-тюнерами бытового уровня для которых перезапуск по питанию только на пользу.
Это справедливо для FreeBSD, при неаварийной перезагрузке нужно использовать shutdown -r
При этом сначала быдет выполняться /etc/rc.shutdown для корректного завершения процессов.
При reboot просто всем пошлётся sigterm, подождёт (по дефолту вроде 30 сек), потом sigkill
Напомнили вопросы на одном из собеседований (лет 10 назад, компания сейчас с Громким именем):
1) кто автор утилиты traceroute?
2) почему Ван выбрал порт 33434 (и как его легко запомнить)?
Ответил на оба, но работать к ним не пошёл. Нахрена мне это знать как простому админу?
Возможность выбора диапазона портов была в первой же версии traceroute, по крайней мере во FreeBSD 1.0 уже присутствовала. Вот выбор протоколов появился только с FreeBSD 4.0.
Если правильно ошибаюсь, то в CentOS-7 её нет.
Да ладно Вам.
Простейшая трассировка:
# traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
1 31.41.40.1 0.569 ms 0.476 ms 0.452 ms
2 10.52.12.1 0.463 ms 0.561 ms 0.514 ms
3 95.213.189.1 0.608 ms 0.549 ms 0.536 ms
4 195.208.208.232 1.539 ms 0.957 ms 1.587 ms
5 66.249.94.100 2.137 ms
66.249.94.94 2.101 ms 1.619 ms
6 66.249.95.241 25.756 ms
64.233.174.85 25.829 ms
209.85.243.149 22.934 ms
7 216.239.56.208 17.262 ms
216.239.40.240 16.171 ms
209.85.247.77 16.547 ms
8 * * *
9 8.8.8.8 14.459 ms 14.591 ms 13.890 ms
Откуда взялся серый адрес на втором хопе?
Почему на 5-6-7 ответы от нескольких ip?
Почему время ответов на 9-м шаге меньше чем на 6-м?
и т.д. и т.п.
О traceroute можно роман написать.
P.S.: ответы не требутся.
20 лет "публично" не переводил, да и сам англоязычный вариант тяжеловат. Он перенасыщен повторяющимися словами, и при переводе не удаётся подобрать "технические" синонимы. В первоначальном варианте хотел частично оставить pipe, redirect и т.п., но в итоге заменил таки, возможно зря. Можно было бы переписать свою статью, но это было бы нечестно по отношению к автору оригинала.
http://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=gethostbyname
так и при реальном разрешении имён, т.к. будет задействован механизм NSCD (если только не делать принудительный invalidate кеша).
С чем его сравнивать?
Говоря о UDP подразумевая SOCK_DGRAM, т.е. на доменах AF_UNIX/AF_INET имеем те же отличия что и при SOCK_STREAM.
Говоря о UDP подразумевая отличия в одном домене имён между SOCK_DGRAM и SOCK_STREAM имеем негарантированную доставку пакета ограниченного размера.
1) Это как раз честно. Представьте socket-клиент в реальных условиях. Будет ли он без gethostbyname?
2) На самом деле вес gethostbyname в массе(да пусть поперхнутся физики) ничтожен. Даже на НЕ-локальных вызовах он окажет куда меньшее влияние чем может оказать, например, размер пакета.
А что PHP или Redis используют некие несистемные средства работы с сокетами?
Листаю исходники redis. Как и ожидалось все функции anetTcp отличаются от anetUnix именно "добавлением" в Tcp-функциях getaddrinfo, bind, ntohs.
Чтение и запись реализованы в "общих" anetRead, anetWrite. И пока не могу полагать, что работа с сокетами одного типа может отличаться чем-то кроме дополнительных расходов на tcp-обработку.
Ссылкой поделитесь?
С чего вдруг?
Сокеты одного типа SOCK_STREAM. За исключением того, что в домене AF_INET мы несём накладные расходы на именование сокета, htonX'ы, муршрутизацию, asc'и принципиальных отличий от AF_UNIX нет. Как следствие, чем меньше длина пакета данных, тем больше будет выигрыш при использовании сокетов в домене файловой системы. Как правило, это порядка 50%.
Поэтому (если исключить правку кода для внедрения в редис IPS с использованием разделяемой памяти) AF_UNIX сокеты будут самыми производительными. А ввиду того, что read/write для них реализован одинаково сравнивать стабильность не приходится.
Ни чистых Insert'ах отправлял в продакшине данные из nginx в MySQL порядка 30'000 qps и это был не предел. На чистой синтетике (в режиме храниения данных а-ля redis — ключ/значение) думаю можно добиться и более 100'000 qps.