Перейти к содержимому
Калькуляторы

Dark_Angel

Активный участник
 Просмотреть профиль  Активность

  • Публикации

    368

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

  • Посещение

 Тип публикации 

Сообщения, опубликованные пользователем Dark_Angel

  1. Опубликовано · Жалоба на ответ

    Это немного проясняет ситуацию, то есть их не интересует способ блокирования домена, они просто хотят чтобы он не открывался. Спасибо.

  2. Опубликовано · Жалоба на ответ

    Ну так вот мой вопрос об этом: что если на их письмо со списком сайтов, которые открываются, отписываться, что ресурсы заблокированы согласно реестра ( где только ИП ). А то что ресурс открывается, так возможно он сменил адрес на тот, которого в реестре нет.

     

    На сколько я понимаю, это будет по букве закона. Пробовал кто-то так делать?

     

    Самописные ресолверы, DPI это, на сколько я понимаю, больше чем требуется по закону, стоит денег и имеет всем понятную цель.

     

    Я из ваших сообщений сделал вывод

    Неверный вывод.

    Скорее всего фильтровали по IP-адресам, в том числе и записи, указанные с доменными именем (преобразуя их).

    А в момент проверки часть сайтов поменяли IP-адреса и не были заблокированы.

     

    Чтобы такого не было, нужно использовать DPI и блокировать до домену/URL.

    Что в конечном итоге было сделано на Carbon Reductor.

     

    Вы пишите "неверный вывод", а потом другими словами пересказываете этот самый вывод.

     

    Закон как-то регламентирует то, когда именно должен быть отресолвлен домен?

  3. Опубликовано · Жалоба на ответ

    Нарушается закон и не в вашу пользу.

    Да не нарушается закон,мы нарушали, не был вовремя выполнен план сорм, не было блокировок реестра, не был сдан узел и тд. Если бы нарушений не было - нас бы и в суд не тягали. Вы странно рассуждает, если бы нас нагибали сверх закона - бились бы до последнего.

     

    Я из ваших сообщений сделал вывод, что штрафовали вас за то, что вы фильтровали трафик по спискам РКН по IP ( как и требуется по закону ) и их убер тулза, естественно, смогла зайти на некоторые УРЛ, которые уже поменяли IP.

     

    Если вас штрафовали за другое, то не понятно какое это имеет отношение к теме?

  4. Опубликовано · Жалоба на ответ

    Адвокат возьмёт гонорар не меньше штрафа, и не факт что выиграет (если выиграет то деньги за гонорар заплатит государство, если всё по чесному оформляли).

    Плюс адвокатов которые сайт от IP и email от mac отличат исчезающе мало, зато разводил "да мы щас порвём их!!!" полно, гонорар получат и потом ищи-свищи их.

    А по таким делам нужно любому адвокату сидеть со спецом и вникать в суть, чтобы понять где и как взять бумажки что ты не верблюд, ибо без бумажек для судьи это всё пустой звук.

     

     

    По вашей логике нужно расслабиться и получать удовольствие. Я с этим в корне не согласен. Нарушается закон и не в вашу пользу. Пусть даже гонорар будет немного больше или равен штрафу, лучше отдать эти деньги на решение вопроса.

     

    Уважаемый товарищ Tem подтверждает это. Кстати, можете поделиться информацией по расчетам с адвокатом? Получилось выгоднее/так же или дороже, чем платить штраф?

  5. Опубликовано · Жалоба на ответ

    Спасибо что делитесь опытом. У нас же не прецедентное право. Почему судьи ссылаются на подобные дела?

     

    Ну без адвоката, конечно, не дело.

     

    Я на самом деле считаю, что вместо покупки DPI и фильтрования как им нужно, нужно бороться за соблюдение закона. У кого-то еще есть опыт отстаивания своих прав?

  6. Опубликовано · Жалоба на ответ

    Я не знаю, поэтому и спрашиваю. То что само заседание короткое - это понятно, вопрос был по временному отрезку от подачи заявления до получения постановления на руки. Включая обжалование решения по всем инстанциям ( вас же оно не устраивает? ).

     

    Или вы не пробовали обжаловать? Что говорят адвокаты? Адвокаты наемные или предоставленные судом? Адвокаты понимают суть вопроса? Каковы их прогнозы?

     

    Мне кажется, что если после нескольких апелляций, суд всеравно идет на нарушение закона, а именно признает вас виновными, то беспокоиться нужно не о том, как там ресурсы блокировать, а как бы нужно ли таким бизнесом вообще заниматься.

     

    Отбрасывая пафос последнего абзаца, хотелось бы действительно узнать судебную практику по этому вопросу.

     

    Заранее спасибо.

  7. Опубликовано · Изменено пользователем Dark_Angel · Жалоба на ответ

    Хотел спросить у уважаемого SyJet а вы в суд пробовали обращаться и обжаловать штраф РКН? Ведь требования закона вы выполнили ( блокировка по списку на 12:00 какого-то дня ), соответственно штраф в такой ситуации не правомерен.

     

    Если обращались, поделитесь пожалуйста деталями: сколько заняло разбирательство и каково было постановление?

  8. Опубликовано · Жалоба на ответ

    Не в поставщиках памяти дело, а в производителях. У меня на участке сейчас в обработке больше 1тыс серверов и поверте, память играет роль. Мы предпочитаем не экономить на этой мелочи, так как уже накололись. Любая более менее серверная сборка автоматом тянет ECC и Xeon.

     

    Вы меня по-диагонали читаете. Я где-то написал, что ЕСС бесполезна вообще всегда? Как ваш опыт с 1 тыс. серверов можно перенести на вопрос ТС?

     

    В этом и суть, что нет ничего абсолютного в отказах, отказоустойчивость - это всегда компромисс между вероятностью отказов и методов, которыми такая вероятность достигается для каждой конкретной задачи. И тут как ни крути, а ECC всего-лишь один из компонентов системы, и он часто настолько мало влияет на общую вероятность, что на него можно не тратиться и вообще пренебречь.

     

    Люди, которые пугают потерей данных без ECC, на самом деле банально ничего в отказах не понимают. Им стоит хотя бы дядюшку Джо послушать, прежде чем фантазировать.

     

    Ну так я абсолютно с вами согласен, тем более в контексте данной темы.

  9. Опубликовано · Изменено пользователем Dark_Angel · Жалоба на ответ

    Деньги считаться будут чужие, не свои. И когда у партнера возникнет вопрос "а с какого хрена мне в 3 раза больше насчитало" - он с большой вероятностью пошлет такого "провайдера" куда подальше.

     

     

    Я с вами не согласен. Это из серии "давайте построим бункер и поставим сервер туда, а то вдруг война". Это оправдывает себя в 0.001% случаев, и кто-то даже так и делает, но их задачи весьма специфичны.

     

    И уж тем более маловероятна ситуация, когда сбой произойдет в ячейке памяти непосредственно баланса и непосредственно перед записью в БД. Потому что произойди он при других обстоятельствах - такие данные будут считаться неконсистентными самой системой и попадут в лог.

     

    Если вам попадается много бракованной памяти, попробуйте поменять производителя, если собираете сами, либо поставщика, если покупаете собранное. Те сервера которые попадают ко мне могут днями гонятся на тестах ( 2 недели тестирование перед продакшеном ), и никаких ошибок на них не вылазит.

     

    Ну и ситуация в которой клиент получив счет на минус триллиард такой "ой, наверное меня хотят обмануть на триллиард" и свалит к другому провайдеру и вовсе комична.

     

    Короче, из моего опыта ECC нужен в очень специфических ситуациях, куда задача поднятая ТС ни при каких условиях не попадает. Даже если там будут считаться миллионы для этих двух клиентов. Затраты на покупку оборудования с ЕСС не окупятся никогда.

     

    Желающим обсудить полезность ЕСС и обменяться реальным опытом, или проверить свои теории предлагаю создать отдельную для этого тему. Я с удовольствием подискутирую и поделюсь своим опытом, т.к. тема весьма не однозначна на первый взгляд.

  10. Опубликовано · Изменено пользователем Dark_Angel · Жалоба на ответ

    Хочу поддержать товарищей которые говорят что ECC в данной ситуации не нужно. Вы вообще о чем? 300 Мбит, 2 организации. Какие ошибки в деньгах при такой нагрузке?

     

    Память, которая дает одну ошибку в сутки на мемтесте, который тестит память линейно - это битая память, т.к. в параллельном тесте она будет сбоить намного чаще.

     

    Занимаюсь разработкой биллинговых систем 12 лет уже.

     

    По теме: видел железки с i7 на борту типа такого: http://ru.aliexpress.com/item/Mini-xp-pc-cloud-mini-pc-mini-pc-desktop-500g-hdd-Intel-core-i7-2600S-2/1518106717.html?recommendVersion=1

     

    Это если мощи мало, но уже начиная с двухядерного атома начинается активное охлаждение. При более мощном раскладе ребристый корпус уже не спасает при постоянной нагрузке.

  11. Опубликовано · Изменено пользователем Dark_Angel · Жалоба на ответ

    Добрый день!

    Помогите, пожалуйста, с раскидыванием прерываний по ядрам.

    Есть 3 сетевые карты 82576 и одна 82574L, всего 8 портов, и процессор Xeon 5500. Драйверы сетевух стоят последние с офсайта. Каким образом лучше всего распределить прерывания?

    Сам я с этим еще не сталкивался

     

    Содержимое /proc/interrupts:

     

     

    cat /proc/interrupts 
          CPU0       CPU1       CPU2       CPU3       
 0:      49943          0          0          0   IO-APIC-edge      timer
 1:         12          0          0          0   IO-APIC-edge      i8042
 8:          1          0          0          0   IO-APIC-edge      rtc0
 9:          0          0          0          0   IO-APIC-fasteoi   acpi
12:        155          0          0          0   IO-APIC-edge      i8042
16:          0          0          0          0   IO-APIC-fasteoi   uhci_hcd:usb3
18:          0          0          0          0   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb8, i801_smbus
19:          0          0          0          0   IO-APIC-fasteoi   uhci_hcd:usb5, uhci_hcd:usb7
21:          0          0          0          0   IO-APIC-fasteoi   uhci_hcd:usb4
23:          0          0          0          0   IO-APIC-fasteoi   ehci_hcd:usb2, uhci_hcd:usb6
42:       6623          0       1228          0   PCI-MSI-edge      ahci
43:        358          0          0          0   PCI-MSI-edge      ioat-msix
44:        358          0          0          0   PCI-MSI-edge      ioat-msix
45:        358          0          0          0   PCI-MSI-edge      ioat-msix
46:        358          0          0          0   PCI-MSI-edge      ioat-msix
47:        358          0          0          0   PCI-MSI-edge      ioat-msix
48:        358          0          0          0   PCI-MSI-edge      ioat-msix
49:        358          0          0          0   PCI-MSI-edge      ioat-msix
50:        358          0          0          0   PCI-MSI-edge      ioat-msix
51:         14          0          0       2108   PCI-MSI-edge      enp6s0-rx-0
52:        748          0          0          0   PCI-MSI-edge      enp6s0-tx-0
53:          2          0          0          0   PCI-MSI-edge      enp6s0
54:          5          0        368          0   PCI-MSI-edge      enp7s0-rx-0
55:          0          0          0          0   PCI-MSI-edge      enp7s0-tx-0
56:          1          0          0          0   PCI-MSI-edge      enp7s0
57:          0          0          0          0   PCI-MSI-edge      enp1s0f0
58:         80        293          0          0   PCI-MSI-edge      enp1s0f0-TxRx-0
59:          0          0          0          0   PCI-MSI-edge      enp1s0f1
60:          5          0        368          0   PCI-MSI-edge      enp1s0f1-TxRx-0
61:          0          0          0          0   PCI-MSI-edge      enp2s0f0
62:         79          0          0        294   PCI-MSI-edge      enp2s0f0-TxRx-0
63:          0          0          0          0   PCI-MSI-edge      enp2s0f1
64:          4          0        369          0   PCI-MSI-edge      enp2s0f1-TxRx-0
65:          0          0          0          0   PCI-MSI-edge      enp3s0f0
66:         79          0        294          0   PCI-MSI-edge      enp3s0f0-TxRx-0
67:          0          0          0          0   PCI-MSI-edge      enp3s0f1
68:          4          0        369          0   PCI-MSI-edge      enp3s0f1-TxRx-0
NMI:         11          4          3          4   Non-maskable interrupts
LOC:       8674      14917      10812      26232   Local timer interrupts
SPU:          0          0          0          0   Spurious interrupts
PMI:         11          4          3          4   Performance monitoring interrupts
IWI:        235        366        533        448   IRQ work interrupts
RTR:          3          0          0          0   APIC ICR read retries
RES:       1519       1534       1203       1104   Rescheduling interrupts
CAL:        642        751        563        636   Function call interrupts
TLB:         31         37         47         19   TLB shootdowns
TRM:          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0   Threshold APIC interrupts
MCE:          0          0          0          0   Machine check exceptions
MCP:          4          4          4          4   Machine check polls
ERR:          0
MIS:          0

     

     

     

    Не совсем понятно зачем вы сделали такую конфигурацию. Ведь 82576 каждая имеет по 8 очередей. То есть у вас 8х3 + 82574L ( вроде бы 2 очереди ) = 25 векторов потенциально. И всего 4 процессора. Процессоры реальные или с HT? Распределять просто: той карте у которой больше всего нагрузка, давать больше всего процессоров. Начинайте с 1 вектора на каждую карту и повесьте их каждый на отдельный процессор. А потом по нагрузке: совмещайте какие-то вектора на одном процессоре, и добавляйте новые вектора на загруженной карте.

     

    Но вообще это изврат. Убежден, что все решила бы одна карта 82576 с ВЛАНами.

  12. Опубликовано · Жалоба на ответ

    Посмотрите imapsync. Синкаете старый на новый в онлайн режиме, когда все работает, сколько надо дней. Потом останавливаете прием писем на старом сервере, выполняете синк еще раз. Он пройдет быстро, т.к. досинкает только новые письма. Готово.

  14. Опубликовано · Изменено пользователем Dark_Angel · Жалоба на ответ

    Какой-то особой отказоустойчивости я от RAID10 не ожидаю.

    Да, если вылетит один диск, массив останется в работе.

    Но однотипные диски в одинаковых условиях и сыпаться начнут одновременно.

    И если выйдет из строя зеркальная пара, то восстановить данные из RAID0 будет ничуть не легче, чем на любом другом RAID.

     

    RAID10 самый отказоустойчивый вариант из всех на большом количестве дисков.

     

    Вы не забывайте, что запись на диски идет в страйпе. То есть вся полка равномерно нагружена, соответственно вероятность того, что выйдут два диска одновременно из одной пары ниже чем вероятность выхода двух дисков вообще ( RAID5, RAID6 ).

     

    Ну и еще важный момент. В случае кошмара и ужаса, когда вышли диски в зеркале в RAID10 вы потенциально можете рейд разобрать до RAID0 и попробовать его поднять с потерями. Тогда как в остальных случаях вы получите просто кашу из данных.

     

    RAID10 не панацея и проблемы у него есть, но пока ничего лучше не придумали, увы.

  15. Опубликовано · Жалоба на ответ

    +1 на таком объеме только RAID10.

     

    У вас по сути вариантов нет:

    RAID3 - это, видимо, промежуточный результат по пути к 5, 6. Проблемы при множественной записи ( ваш случай ), ну и вообще побитовый страйп - это дичь.

    RAID5 - можно потерять только один диск + не быстр на запись.

    RAID6 - можно потерять только два диска + не быстр на запись.

    RAID10 - можно потерять хоть половину дисков из разных зеркал, наивысшая производительность из доступных рейдов, а именно сумма iops половины дисков.

  18. Опубликовано · Жалоба на ответ

    Спасибо за объяснения, парни. А до какого значения вы крутили ITR?

     

    Потому как моя логика следующая: раз очередь переполняется и её размер уже максимален ( вы ведь поставили ring buffer в 4096? ), значит нужно выгребать её чаще, что можно сделать чаще прерываясь. Например, в 2 раза больше, чем прерывается, когда есть ошибки.

     

    То есть больше очередей в данной ситуации выглядит как хак. Не самый плохой, но тем не менее.

     

    Ну и да, похоже ошибки набегают от всплеска за промежуток замера.

  19. Опубликовано · Жалоба на ответ

    Так а вы уверены, что именно увеличение количества очередей является решением, а не ядро и драйвер, например?

     

    Ну и если ответ да, то, мне кажется, что-то тут не так. Очереди у вас гибридные? Если да, то их увеличение больше количества процессоров только увеличивает оверхед. Может тогда нужно ITR руками подкрутить, чтобы чаще выгребать буфера карт?

  20. Опубликовано · Жалоба на ответ

    Кстати у меня такой же вопрос. Как правильно всех расшейпить на негарантированном канале? Скажем емкость может снизиться в 2 раза.

     

    Желательное поведение, чтобы приоритетный трафик например UDP, SSH и др. шел первым, а следом уже второстепенный. Можно решить эту задачу как-то через tc?

  22. Опубликовано · Изменено пользователем Dark_Angel · Жалоба на ответ

    Я обратного и не утверждал.

     

    "Поэтому, по-моему лучше выключать RPS/XPS если о не нужен."

     

    В моем примере выше, XPS нужен для размазывания очередей отправки пакетов для туннелированных пакетов. Штатный RSS свалит всё в одну чередь.

  23. Опубликовано · Жалоба на ответ

    Ну это сомнительное утверждение. Пока всё работает - это, возможно, и не важно. Но как только начнутся проблемы, понять что и как обрабатывается будет сложнее. Поэтому, по-моему лучше выключать RPS/XPS если о не нужен.

     

    Я придумал только одно исключение - это терминирование туннелей. Туннели нормально RSS не обрабатываются в современных сетевых картах, поэтому нужно включать RPS, чтобы это хоть как-то было не на одно ядро. В этом случае нормальные пакеты и деинкапсулированные пакеты будут разруливаться картой, а туннели RPS/XPS.

  24. Опубликовано · Жалоба на ответ

    Слушайте, ну 2.5 Гбита для современных машин, это вообще ни о чем. Даже тюнинговать ничего не надо.

     

    Правда не совсем понятно почему у вас вход != выходу. Да еще и разница в 2.5 раза.