Перейти к содержимому

ttttt

Сitizens
  • Публикации

    2 081
  • Зарегистрирован

  • Посещение

  • Дней в лидерах

    14

Все публикации пользователя ttttt

  1. Бесперебойник сам часто причина пропадания питания. Кроме того от других причин повреждения ФС это не защитит, как хардовых, от которых сервер виснет, типа SATA кабель от вибрации стал отходить, перегрев и т.д., так и софтовых, типа глюков в драйверах, ядре и т.д.
  2. Norther, с ваших слов получается, что выигрывает тот, кто пересидит кризис, так? Логично в общем-то, только пересиживать придется аж до 2016-го.
  3. Бэкап на два разных винта. Только бэкап еще надо уметь делать. Тупо копировать файлы - самая плохая идея и надежности особенно не добавляет: когда-то что-то затрется или ошибка какая-то или вирус или еще что, очнетесь, а в бэкапе уже этот же мусор и восстановить ничего нельзя. Правильно - это не тупо копировать, а делать инкрементальный бэкап и иметь возможность откатиться на любую дату. Кроме этого, бэкап еще нужно проверять восстановлением, а то у вас может быть все супер круто и инкрементально, но где-то данные игнорируются из-за какой-то ошибки или багофичи, а вы не знаете и в итоге данные
  4. Столько времени прошло, а человек все еще ищет VPS. Сколько тем на этом форуме было? С десяток?
  5. ttttt

    Интернет для квартиры

    Юрка, берите два провайдера, стабильность одного - это все выдумки и сказки для деток.
  6. 1000 это уже топ, реально их порядка 20000
  7. Зря тут это как юмор рассматривают. У нас всего где-то 1000 форумов, которые охватывают всю аудиторию уанета, можно очень прилично "поправить мнение".
  8. ttttt

    Билинг для 300-500 абонентов.

    Это все бурное воображение и в общем-то бред. Вы сильно переоцениваете возможности, надежность мускуля и критичность ваших данных. RPC сервис тут был бы гораздо лучшим решением, чем костыли на SQL.
  9. ttttt

    Билинг для 300-500 абонентов.

    Боже упаси
  10. ttttt

    Билинг для 300-500 абонентов.

    http://search.cpan.org/search?query=AnyEvent+mysql&mode=allhttps://www.npmjs.org/search?q=mysql http://twistedmatrix.com/documents/current/core/howto/rdbms.html https://code.google.com/p/go-wiki/wiki/SQLDrivers Все давно переписано. Вообще разговор ни о чем уже. Вы с чего-то вдруг решили, что планировщик на sql костылях - это нормально. Пилите, имеете проблемы, но продолжаете жрать кактус. Ваше дело. Но это говнокод и ламерство. Асмодеус, вы такой программист, как я балерина, молчали бы уже
  11. ttttt

    Билинг для 300-500 абонентов.

    Зачем? О чем разговор вообще? Я в контексте выноса логики планировщика из СУБД в отдельный сервис. А куда оно делось? Гоняли себе данные туда-сюда, а вдруг перестали? Ерунда. Это скорее для "масштабируемого" многопоточного кода будет проблемой. Lock contention, блокирующие вызовы, рейсы. Вот весело кому-то будет.
  12. ttttt

    Билинг для 300-500 абонентов.

    Да как-то не заметил, что там CPU кодирует mp4 на каждый запрос авторизации, все SQL запросики, СУБД, плохо смотрю? Дык а какая разница, что вы собираетесь выиграть от асинхронности запроса раз в 5 секунд? Не имеет значение в реальной жизни С ними там сложная долгая история, они так и не прижились и не приживутся, вместо них прижились event loop'ы и целая масса разных асинхронных фреймворков. А вот в Питоне наоброт, даже несмотря на глобальный лок, очень много кто использует потоки по дурости, а асинхронный код там не очень популярен.
  13. ttttt

    Билинг для 300-500 абонентов.

    Не совсем в порядке очереди запросов, запросы принимаются асинхронно, не блокируя другие (в том смысле, что ядро ОС продолжает заполнять буфера сокетов), а когда какой-то запрос принят, то вызывается его обработчик. Обработчик потом не отдает данные клиенту, а ложит их в буфер, которые будут не блокируясь отправлены. Всем этим заведует единый бесконечный цикл, который собирает события от ядра через select()/epoll(). Плохо я описал, без псевдокода такую архитектуру не описать, но это типичный event loop и типичное event-driven программирование. Такой код обычно проще, чем параллельный, и его пр
  14. ttttt

    Билинг для 300-500 абонентов.

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

    Билинг для 300-500 абонентов.

    Из этой темы и показанных костылей Если нет логики в СУБД, то при нормальной работе в СУБД должны только сохраняться конфиг/пулы/изменения_в_пулах раз в сколько-то секунд и все. Покажите статус процесса радиус сервера, на select/epoll/kqueue висит? Если да, то он асинхронный. Если у вас не упирается в СУБД, то это далеко не большие нагрузки Но речь сейчас не об этом, а о том, что неадекватно реализовано, из-за чего локи, пиление и прочие проблемы даже на микронагрузках.
  16. ttttt

    Билинг для 300-500 абонентов.

    И? А логика зачем-то в СУБД. Очень умно. Точнее, большего маразма трудно представить (а вообще я не смотрел радиус, может он там через одно место писан, с prefork моделью, а не асинхронно, потому маленький сервис может быть очень хорошей идеей)
  17. ttttt

    Билинг для 300-500 абонентов.

    Из файловой системы или даже из СУБД. Суть не в том где хранить, а где логика реализуется. О, к чему-то пришли. В радиус сервер можно и воткнуть планировщик, а в СУБД исключительно сохранять/брать конфиг. Зачем memcached? В этой теме уже на несколько страниц костылей в СУБД и каждый для себя что-то пилил, потому что, кхм, "работает без проблем", да, именно так
  18. ttttt

    Билинг для 300-500 абонентов.

    Ну вот вместо всех этих попыток пихать логику планировщика в СУБД написать маленький сервис, который эту логику реализует и общаться с этим сервисом, а не с СУБД.
  19. ttttt

    Билинг для 300-500 абонентов.

    Вынести раздачу адресов в отдельный сервис или это слишком сложно для асмодеусов? Задача вообще-то совсем не для СУБД и использовать СУБД в качестве планировщика ресурсов - тот еще маразм.
  20. В СМИ опять "эксперты" нагнетают. По заказу банков, не иначе.
  21. ttttt

    Гигатранс , екс.уа и другое

    Примерно так. Там часть дисков на части серверов всегда перегружена, ибо только часть серверов используются для новых файлов. Они не раскладываются по всем дискам всех серверов.
  22. Алекс, давайте разберемся для начала, что точно делать, а там уже будет кому делать. Пока тут толком не ясно, что вы именно хотите. Я вижу это так: не девайс, а софт в виде сервера и клиента для ноутбуков/нетбуков/роутеров, с гуи, но через браузер. Клиент меряет время до соединения с сервером и скорость обмена с сервером и больше ничего. EDIT: или вообще сам браузер и есть клиент, типа такого http://proof.ovh.net/
  23. ttttt

    DDoS на Mikrotik

    В CERT-UA еще напишите: http://cert.gov.ua/?page_id=295
  24. ttttt

    DDoS на Mikrotik

    С постов понял, что атакуют айпишник NATа, а он просто по совместительству оказался микротиком? Причем атака малюсенькая, т.к. все успешно роутится машинкой на FreeBSD на этот микротик. Так? Тогда может хватить простых правил ipfw, но стоит готовиться, что атака может продолжиться с большей силой и машинка на freebsd тоже умрет. От бесплатно до сколько смогут стянуть. Цены отличаются на пять порядков.
  25. Сколько там малинка вытягивает? 15 мбит? Или целых 20? Прогуляйтесь по их форумам, 100 мбит через юсб2.0-езернет адаптер у всех тянет Я и сам пробовал через отг к планшету, скорость не мерял, но по ощущениям было быстро, как обычный езернет. Отг ж юсб2.0.
×
×
  • Создать...