LoTW

[RX4HX]

Для интереса подсчитал - сейчас в очереди почти 5,5 млн. QSO, очередь на 18 часов. В итоге на 1 QSO приходится -
18*60*60/5500000=0.012 сек
что для такой базы вполне нормально.

[RX3APM]

для такой базы вполне нормально.

Как то очень голословно звучит
Для какой базы ?
Что именно нормально, точнее, на что идут те посчитанные 0.012 сек ?
Прошу пояснить.

Я вот считаю, что ненормально.
Чтобы не быть голословным, поясню:
Если внимательно последить за той таблице, откуда вы взяли часы и миллионы, то видно, что время в очереди вовсе не коррелирует с количеством миллионов щсо. А именно, вчера щсо доходило аж до 8 миллионов, а очередь была меньше. Сейчас осталось всего 5.1млн щсо, а очередь стала больше по времени.
Немного коррелировало в течение последние суток с количеством логов, но в последние часы и эта корреляция нарушилась.
Ну и главное, непонятно на что же уходит такое огромное время.
Объем логов ничтожен, микроскопичен буквально, и все логи уже приняты сервером, но стоят в очереди.
Якобы идёт «вычисление» какое-то, или «поиск соответствий».
Но и тут нестыковка, все логи целиком легко поместятся в оперативную память средненького компьютера, даже тратить время на обращение к диску не придется, будь он даже сверхбыстрый SSD. То есть останется процессору просто в оперативную память обращаться и вычислять с теми самыми миллионами операций в секунду.
Из этого вывод, что все должно быть обработано если не за секунды, то за минуты, а не 18 часов, как сейчас там очередь нарисована.
Такое впечатление, что идёт не непрерывная работа по отработке, а какими-то порциями и очень периодически.

[RA0FF]

а не 18 часов, как сейчас там очередь нарисована.

У меня даже часов 20 вышло с момента как я лог, в котором было 242 связи, выгрузил и как он был обработан.
Все это время, естественно, на моей страничке лотв в разделе "Активность" не было инфо, что мной лог загружен.

[ER1CS]

Из этого вывод, что все должно быть обработано если не за секунды, то за минуты, а не 18 часов, как сейчас там очередь нарисована.

Может вы подсобите своим опытом и дидактической поддержкой командам, которые делают платформу для дипломных программ СРР? Без шуток. Если будет создана площадка с быстродействием, в разы большим чем ныне существующие площадки - это будет очень хорошо для популяризации этих дипломов.

А лотва пусть не быстро, но работает, и это тоже хорошо.

[RX3APM]

Без шуток

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

[ER1CS]

то растолкуйте, на что уходит то огромное время, которое мы видим

То есть вот это -

Объем логов ничтожен, микроскопичен буквально, и все логи уже приняты сервером, но стоят в очереди.
Якобы идёт «вычисление» какое-то, или «поиск соответствий».
Но и тут нестыковка, все логи целиком легко поместятся в оперативную память средненького компьютера, даже тратить время на обращение к диску не придется, будь он даже сверхбыстрый SSD. То есть останется процессору просто в оперативную память обращаться и вычислять с теми самыми миллионами операций в секунду.
Из этого вывод, что все должно быть обработано если не за секунды, то за минуты, а не 18 часов, как сейчас там очередь нарисована.

Вы высказали не на основе личного опыта и знаний?

[RX3APM]

То есть вот это -


Вы высказали не на основе личного опыта и знаний?

То, что я написал подпадает под личный опыт и знания любого развитого человека.
А именно: объем логов в очереди составляет всего 2.2 гигабайта (это видно из таблицы)
Такой объем целиком помещается в оперативную память и обрабатывается.
Причём там даже не стоит задача что-то вычислять.
На что время то тратить ???
Вы не отвечайте вопросом на вопрос, вы растолкуйте.
Но вы не знаете же толком.
Поэтому ваши реплики бессмысленны.

[RA0FF]

На что время то тратить ???

Сергей, я тут где-то ниже шутканул про Касперского...
Может там действительно после инцидента тщательнее стали входящие логи перлюстрировать и по антивирусникам их разным прогонять?
Вполне возможно, что и в дальнейшем так и будет, что любой лог будет обрабатываться 1-3 суток...

[RV9UP]

Такой объем целиком помещается в оперативную память

И этот объём будет храниться в оперативной памяти? Или же надо куда-то записать?
Причём в рассматриваемом контексте параметром влияющим на длительность операции, если сильно упрощать, является не объём, а количество записей.
Можно посчитать упрощённо:
1. Принимаем 2ГБ=2 000 000 000 байт.
2. Размер одной записи (QSO) принимаем равным 1000 байт.
3. Количество записей 2 000 000 (два миллиона).
4. Принимаем длительность процесса запись+индексирование равным 10 мс (десять миллисекунд).
5. На два миллиона записей потребуется 20 000 секунд или почти 6(шесть) часов работы БД только чтобы записать данные. БД работает только на запись и не обрабатывает внешние запросы.

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

[UA0DM]

1000 байт на QSO это целая радиограмма будет, а не QSO )))

[RX4HX]

все логи целиком легко поместятся в оперативную память средненького компьютера

Вы совсем не с той стороны смотрите. Причем тут логи и их объем? Время уходит не на логи, а на работу с базой. Вам когда-нибудь как программисту приходилось работать с такой огромной базой?
Как все (наверное!) работает на Лотв (я точно не знаю, но предполагаю, что это так):
- файл загружается и обрабатывается на "входном" компьютере
- далее обработанные данные передаются в для записи в базу (скорее всего по сети!) - вот как раз тут и тратится основное время.
И я Вам говорю - это вполне нормальное время. Не понимаю о чем спор?
Да ну и самое главное: даже если Вы не верите мне, ну Вы ж не предполагаете, что разработчики Лотв такие тупые, что специально замедляют время внесения в базу?

вчера щсо доходило аж до 8 миллионов, а очередь была меньше.

Не верю! ))) Псе - принтскрин! Вот тут -

все четко коррелируется - количество QSO - время очереди!

[apm-2]

de RX3APM

Извините, несколько человек мне ответили, попробую вот так.

Итак, RV9UP утверждает, что на каждую-каждую щсо из 5 миллионов идет обращение к диску для записи ?
И при этом из оперативки используется всего 1000 байт, как он посчитал ?
Не слишком ли жирно, точнее, расточительно такое использование ресурсов компьютера ?
Так и год можно большую базу обрабатывать.
А почему именно по одной щсо запись ? А не хотя бы по одному логу из очереди в оперативную память брать, и лог целиком записывать ? Сразу экономия времени в 115 раз получится, так как именно 115 щсо в среднем содержится во всех слогах в текущей очереди.
А для чего тогда придуманы большие объемы оперативки ?
64 гига, 128 гигов, 256 гигов, и так далее ?
Не для того ли, чтобы для обработки в них по-максимуму загружать весь объем для увеличения скорости ?
Как вы думаете вся база лотв со всеми потрохами сколько весит вообще ? Учитывая, что там просто цифро-буквенные таблицы ? Не поместится ли она целиком в оперативку ? Думаю вполне.
Далее, RX4HX утверждает нечто похожее, что идет обращение не просто к диску , а аж по сети с компа на комп, но правда не за каждой щсо, а для каждого загруженного лога, коих в очереди сейчас около 45000. Тоже странно и долго.
Я лично считаю, что там просто старый древний комп стоит, который не тянет. Нечто офисное 10-15 летней давности с 4-8 гигов оперативной памяти и медленным HDD, а не современным SSD. Потому по миллиону раз и гоняется туда-сюда из оперативки на диск и обратно.
Современный комп с большой памятью проглотил бы всю базу прямиком в ОЗУ и там бы быстро оприходовал все наши буковки и циферки в несложные таблички.

[UN7JID]

Насколько я помню, промелькивала цифра объема БД LOTW в 3 терабайта. Сомневаюсь, что такой объем влезет в оперативку, учитывая что в БД он хранится в зашифрованном виде, скорее всего.
То, что серваки там стоят явно не последнего поколения, это логично. Все всегда стараются не обновлять железо до того момента, пока край не наступит.
Зачем? Работает же.
Уж кто-кто, а американцы деньги считать умеют.
Так что все идет закономерно.потихоньку ажиотаж рассасывается, не спеша, медленно, но верно.
Лишь бы работало. А подождать - мы подождем.

[UI3A]

что на каждую-каждую щсо из 5 миллионов идет обращение к диску для записи

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

с одной стороны индексы помогают при поиске данных (например, подтвердить двухстороннее qso RX3APM с Буве), но с другой стороны - чем больше данных - тем больше размер этого индекса(ов) и при добавлении данных в таблицы необходимо индексы обновлять, перестраивать...

у разных БД эта работа организована по разному и тут выбирают как с индексами работать исходя из задач.
если упрощенно, то если много запросов на поиск в БД данных - значит много индексов, но медленная вставка данных, если данные ищем редко (или можем подождать), то индексов поменьше, данные вставляются быстро.

[ER1CS]

все гораздо хуже и сложнее.

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

Возвращаемся к обсуждению насущных проблем LoTW - доступов, подтверждений, паролей, сертификатов, tqsl и подобному.

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