HackFresse писал(а):Не стоит хвататься за одно, не доделав до конца другое, много времени будет на переключение тратиться, + многократно усложненный дебаг.
я каждый день переключаюсь на разные задачи: oracle, linux, C++ Builder, вечерами - VC++ и флайлинк.
также дубликатная посылка данных в один UDP порт это разве не усугубление ddos?
HackFresse писал(а):Видел ситуацию, когда один файл у одного юзера через один хаб качается, а на другом статус показывает, что я 98 в очереди.
Как это сделано - можешь рассказать на уровне протокола - может это фишка грея, он там вроде на уровне хаба что-то умеет срезать?
У флая специально была сделана защита чтобы один файл не качался с одного юзера через разные хабы (иначе тратятся слоты т.к. они глобальные).
и она правда плохо работает и иногда пропускает
проблема отражена тут: http://code.google.com/p/flylinkdc/issu ... il?id=1102
Когда вы вводите поиск файла X , то в результатах поиска отображается этот файл у одного юзера но сидящего на N разных хабах.
при этом
* на вашем клиенте сетевой интерфейс принял N однотипных UDP пакетов и героически их распарсил построив дерево результата
* на другой стороне клиент N-раз! произвел поиск по своей шаре файл X и сформировал эти дубликатные запросы.
Почему так сделано? это по-моему намного хуже экзотических ддос от извращенцев-админов.
KCAHDEP писал(а):Вот за это точно какахами закидают не отмоешься
У меня отмазка есть: Я новичок в Линуксах. А те, кто переходят из одной системы, у тех всегда "ломка" по бывшей. . Особенно, если в ней проработал много лет и всё устраивало .
А вообще, у меня такое подозрение, что линуксовские клинты ДЦ++ давно заброшены и много лет не обновлялись. Так, что твоё желание о том, что было бы не плохо, если бы Флай появился бы и для Линукса, я поддерживаю. Будем надеяться, что найдётся человек, который допилит линуксовские клиенты хотя бы до уровня Флая (можно и лучше, ибо о виндовских прогах мне скоро придётся забыть и найти им всем аналоги, либо отказаться совсем)
flylinkdc писал(а):если подобны ситуации отрабатывать заведя короткоживущий хеш-мап с ключем IP+Port+TTH и слать только один UDP пакет экономя траф и свой и клиентов...
по ADC по-моему ситуация аналогичная...
2. активно скидывает в базу данных FlylinkDC_stat.sqlite статистику которую потом можно перетащить в sql сервер или просто делать запросы из Firefox (https://code.google.com/p/sqlite-manager/) или другой смотрелки sqlite
что бы банить порношариков (банить юзеров с порно шарой)
trolley.di-strict.ru [IP домена 178.49.71.133], в логе пишет, что хаб-домен ддосит IP хаба
у бота свой список TTH порнухи, или по ключевым словам, по которым он ищет на хабике, где стоит этот бот, порнуху, запрещает юзеру поиск по тому же списку.
Последний раз редактировалось Kimbo 10 фев 2014, 18:23, всего редактировалось 2 раза.
flylinkdc писал(а):это ведь не ddos - как отделить?...
Я так понял хаб ищет в активе и в поисковом запросе ip получателя соответствует ip хаба. Но я бы не говорил что это не ddos. Если хаб шлет запросы слишком часто, то почему не?
что значит "шлет запросы слишком часто"? 1 запрос за 4 секунды, или 4 запроса за 1 секунду? Откуда вдруг появилось ограничение 10 раз за 60 секунд? Вот именно, если вы понимаете, о чем я ..
Если уж есть возможность внедрять сразу кучу фич (хотя это бывает очень редко и делать такое очень тяжело), то очень нужно ведение базы данных в оперативной памяти, и лишь периодический сброс её копии на диск. Поштучная запись чего-то (по одной строке) очень сильно напрягает файловую систему даже до непосредственной раздачи файлов
Вложения
а еще артефакты при отрисовке статусных сообщений
myinfo.jpg (111.95 КБ) 11859 просмотров
Последний раз редактировалось HackFresse 10 фев 2014, 22:43, всего редактировалось 1 раз.
andruw писал(а):Я так понял хаб ищет в активе и в поисковом запросе ip получателя соответствует ip хаба.
что за бред.
andruw писал(а):Но я бы не говорил что это не ddos.Если хаб шлет запросы слишком часто, то почему не?
а я утверждаю, что это не ддос, это поисковой бот-антипорно, у самого такой стоял когда-то.
Или по твоему хаб сам себя ддосит? вообще чушь несёшь. Можете создателю бота написать вопрос, его ник district
Это другой детект и он был давно
тут идет от хаба не известная команда $myinfo
по протоколу команды регистрозависиммая
но данный хаб почему-то приводит все к нижнему регистру и флай его игнорит.
HackFresse писал(а):Если уж есть возможность внедрять сразу кучу фич (хотя это бывает очень редко и делать такое очень тяжело), то очень нужно ведение базы данных в оперативной памяти, и лишь периодический сброс её копии на диск. Поштучная запись чего-то (по одной строке) очень сильно напрягает файловую систему даже до непосредственной раздачи файлов
Тут больше тормозит не диск а проброс сообщения в спикер главного окна для отображения во всплывающей подсказке
вообще логи на то и логи чтобы сразу на диск скидываться - в линуксовых *syslog-ах даже специальная опция есть
сброс сразу на диск чтобы ничего в памяти не висело иначе в случае краха не разберемся в причинах.
также у сислога есть фича упаковки нескольких одинаковых мессаг в одну запись на диске но тут тоже не наш случай...
я пока не знаю как быть. может эту ошибку просто не выводить в данный лог а просто тихо игнорить как это делают другие клиенты.
HackFresse писал(а):всё относительно.
что значит "шлет запросы слишком часто"? 1 запрос за 4 секунды, или 4 запроса за 1 секунду? Откуда вдруг появилось ограничение 10 раз за 60 секунд? Вот именно, если вы понимаете, о чем я ..
Когда я спросил какие выберем критерии - все отмолчались вот я придумал первое попавшееся 10 раз в минуту.
давайте корректировать правила бана.
тут идет от хаба не известная команда $myinfo
по протоколу команды регистрозависиммая
но данный хаб почему-то приводит все к нижнему регистру и флай его игнорит.
подозрение на ботоводство. если не дело в самом хабе, то ошибка в скрипте, который рассылает инфу о юзерах (меняет пришедшую от реальных юзеров или генерит свою фейковую)
Тут больше тормозит не диск а проброс сообщения в спикер главного окна для отображения во всплывающей подсказке
Мой старый винт периодически похрустывает, но проблема не была значимой при обычной работе (в том числе закачки через uTorrent, грей), пока я не поставил флайлинк. Теперь хруст прям бесит (без раздачи и скачивания файлов).
Запуск очень долгий (создание файлов с базами), при открытии пачки хабов жесточайший зависон и упорное дёргание файла с базой. Хруст при каждой записи в процессе работы (хабов много - записей много) Но самое печальное - после закрытия окна флай процесс еще секунд 20 пытается что-то писать в базу. Слишком частое использование жесткого диска для записи множества мелких порций информации не есть хорошо.
Работа с базой на диске однозначно узкое место. С выносом некоторых таблиц (если не всей базы) в память тормоза приложения заметно уменьшатся
HackFresse писал(а):Работа с базой на диске однозначно узкое место. С выносом некоторых таблиц (если не всей базы) в память тормоза приложения заметно уменьшатся
if (g_DisableSQLiteWAL || BOOLSETTING(SQLITE_USE_JOURNAL_MEMORY))
{
pragma_executor("journal_mode=MEMORY");
}
1. Попробуй запустить флай с FlylinkDC.exe /nowal
2. В настройках вруби галку SQLITE_USE_JOURNAL_MEMORY, // "Keeps a SQLite log file in a memory. It may cause database corruption due an error in the program or system."
Сравни.
У тебя не должны будут создаваться журналы транзакций и все будет лежать в памяти:
Визуально эффект есть?
Также если не сложно замерь скорость конвертации CustomLocations.ini при первом старте но с ключем /nowal
и скинь логи с метриками сколько там msек было и стало.
HackFresse писал(а):одозрение на ботоводство. если не дело в самом хабе, то ошибка в скрипте, который рассылает инфу о юзерах (меняет пришедшую от реальных юзеров или генерит свою фейковую)
Что делать - не выдавать такую диагностику?
ведь без нее юзера не заметят что хаб глючный и не сообщат админу чтобы починил.
Также давай вернемся к детекту DDoS-а что скорректировать (я вечером еще немного логи причешу чтобы красивей выводили инфу)
У вас по логам вообще много поймалось злодеев?
у меня что-то за ночь совсем мало...
Kimbo писал(а):а я утверждаю, что это не ддос, это поисковой бот-антипорно, у самого такой стоял когда-то.Или по твоему хаб сам себя ддосит? вообще чушь несёшь. Можете создателю бота написать вопрос, его ник district
Хаб досит пользователей поисковыми запросами, а те в ответ досят хаб ответами на его поисковые запросы, такой ответ устраивает?
Насчет DDoS-a, поиск альтернатив может слать много tth запросов от одного пользователя пока он качает файлы. Если хаб не режет запросы - все они напрямую отправятся клиентам и это не будет флуд, а вполне полезная нагрузка. Можно сделать глобальный лимит, например отслеживать загрузку сети пользователя или проца и или просто установить фиксированную частоту и включать фильтр только при превышении порогового значения.
Потом я посмотрел, если пользователь ищет в пассиве на нескольких хабах, то ответ надо слать всем, потому как хабы фильтруют часть ответов просто по количеству или запоздавшие.
[2014-02-11 20:13:05] select id from fly_dic where name='[ru] EUNnet (Urals State Academy of Railway Transport) Екатеринбург' and dic=5
[2014-02-11 20:13:05] begin;
[2014-02-11 20:13:05] insert into fly_dic (dic,name) values(5,'[ru] EUNnet (Urals State Academy of Railway Transport) Екатеринбург')
[2014-02-11 20:13:05] commit;
[2014-02-11 20:13:06] select id from fly_dic where name='[ru] EUNnet (Ural State University (Lyceum) Екатеринбург' and dic=5
[2014-02-11 20:13:06] begin;
[2014-02-11 20:13:06] insert into fly_dic (dic,name) values(5,'[ru] EUNnet (Ural State University (Lyceum) Екатеринбург')
[2014-02-11 20:13:06] commit;
Как итог можно сказать, что связка PHP и SQLite вполне работоспособна для невысоко нагруженных проектов. Достаточно придерживаться некоторых простых правил:
Используем WAL-режим журналирования.
Не забываем устанавливать Busy Timeout.
Запись объединяем в транзакции. Причем не простые, а “BEGIN IMMEDIATE”.
У меня был WAL режим с момента его появленяи в sqlite - недавно отказался.
т.к. у некоторого мелкого процента пользователей разрушается база http://www.sql.ru/forum/actualutils.asp ... g=15348853
WAL это относительно новый режим в sqlite - думаю там не все так хорошо
в Firefox на него перешли а вот Google Chrome остался на PERSIST режиме
я добавил новый кей /sqlite_use_wal - счас соберу сборку. сможешь проверить с WAL и PERSIST?
в sqlite данные влетели за 3 секунды
что делал флай остальное время - пока для меня вопрос...
можешь посмотреть код функции void Util::loadCustomlocations()
может что заметишь плохое.
Странно то что мой древний нет-бук делает эту операцию намного быстрее...
какие будут идеи для локализации тормозов в 6 минут?
HackFresse писал(а):
В залогированных запросах жесть вида
[2014-02-11 20:13:05] select id from fly_dic where name='[ru] EUNnet (Urals State Academy of Railway Transport) Екатеринбург' and dic=5
[2014-02-11 20:13:05] begin;
[2014-02-11 20:13:05] insert into fly_dic (dic,name) values(5,'[ru] EUNnet (Urals State Academy of Railway Transport) Екатеринбург')
Это у меня справочник - классическая нормализация.
ты разве не видел модель хранения грея - они даже путь до файла разбирают на части и хранят "цепочкой"
я сделал это для экономии места - названия сетей иногда повторяются вот так:
89.105.144.0-89.105.145.255 592,[ru] KrosLine Красноярск
89.105.149.0-89.105.150.255 592,[ru] KrosLine Красноярск
89.105.152.0-89.105.153.255 592,[ru] KrosLine Красноярск
89.105.155.0-89.105.155.255 592,[ru] KrosLine Красноярск
89.105.158.0-89.105.158.255 592,[ru] KrosLine Красноярск
93.159.244.0-93.159.247.255 592,[ru] KrosLine Красноярск
95.170.184.0-95.170.191.255 592,[ru] KrosLine Красноярск
178.169.64.0-178.169.71.255 592,[ru] KrosLine Красноярск
178.169.88.0-178.169.95.255 592,[ru] KrosLine Красноярск
я в результирующей таблице после преобразования вместо "[ru] KrosLine Красноярск" (24 байта) храню внешний кей в виде числа (2-4 байта)
Хотя в данном случае может стоит попробовать залить напрямую...
с GeoIPCountryWhois.csv аналогично - страны прокидываю через справочник и получаю ID-шки.
Последний раз редактировалось flylinkdc 11 фев 2014, 22:30, всего редактировалось 1 раз.
При большом количестве вставок в таблицу (insert) SQLite сильно тормозит и нагружает жесткий диск.
Это происходит из-за того, что каждый insert пишется на жесткий диск чтобы не потерять данные.
Здесь написано чуть подробнее: http://www.sqlite.org/faq.html#q19.
Есть разные способы решить проблему (тут много информации по оптимизации SQLite, не только для insert).
Я выбрал способ помещать сразу много (пятьдесят) insert-запросов в одну транзакцию.
В результате 12.5 тысяч insert’ов выполняются за 7 секунд (C++, дебаговая версия).
До этого 6.3 тысяч insert’ов выполнились за 11 минут(!) и нагрели винт до 57 градусов.
(19) INSERT is really slow - I can only do few dozen INSERTs per second
Actually, SQLite will easily do 50,000 or more INSERT statements per second on an average desktop computer. But it will only do a few dozen transactions per second. Transaction speed is limited by the rotational speed of your disk drive. A transaction normally requires two complete rotations of the disk platter, which on a 7200RPM disk drive limits you to about 60 transactions per second.
Transaction speed is limited by disk drive speed because (by default) SQLite actually waits until the data really is safely stored on the disk surface before the transaction is complete. That way, if you suddenly lose power or if your OS crashes, your data is still safe. For details, read about atomic commit in SQLite..
By default, each INSERT statement is its own transaction. But if you surround multiple INSERT statements with BEGIN...COMMIT then all the inserts are grouped into a single transaction. The time needed to commit the transaction is amortized over all the enclosed insert statements and so the time per insert statement is greatly reduced.
Another option is to run PRAGMA synchronous=OFF. This command will cause SQLite to not wait on data to reach the disk surface, which will make write operations appear to be much faster. But if you lose power in the middle of a transaction, your database file might go corrupt.
HackFresse писал(а):что делал флай остальное время - пока для меня вопрос...
не вопрос:
Сомнительно что это происходит после...
Посмотри код функци Util::loadCustomlocations
эта операция "insert into fly_dic" выполняется раньше - при парсинге каждой записи CustomLocations.ini
l_item.m_dic_country_location_ip = CFlylinkDBManager::getInstance()->get_dic_location_id(l_networkName);
когда в памяти формирует массив для сброса готового массива в таблицу location_db.fly_location_ip
сам сброс по твоему логу выполняется 3 секунды
Остальные 6 минут отрабатывают деструкторы локальных объектов и что-то еще...
эти вставки выполняется до(!) команды [Start] [CustomLocation-sqlite]
Массовые инсерты я не знаю как сделать - у меня функция не тупо инсертит, она перед этим еще и ищет чтобы там не было
такого значения + естественно возвращается ID записи которую нашла или только что вставила.
Как поменять алгоритм пока не знаю.
PRAGMA synchronous=OFF - я тоже недавно добавил но это опять для защиты от разрушения БД.
Но самое странное, что твои тормоза аномальные - у меня на нетбуке (atom 1,5) выполняется вся операция за 2 секунды.
кто-то в еще имеет слабый комп? проведите простой эксперимент?
Делается это так
1. включаете системный лог в настройках
2. закрываете флай
3. открываете блокнотом файл CustomLocations.ini - делаете там незначительно изменение
(например добавляете пустую строку чтобы поменялась метка времени.)
4. запускаете флай снова
5. открываете системный лог флайлинка и находите там строки [Stop ] [CustomLocations.ini]
этот кусок кидаете сюда + конфигурацию вашей системы.