crower: (Default)
На работе стоит комп с убунтой. Комп не молодой уже, но не задохлик какой-то и среди остального компьютерного парка чуть ли не самый шустрый. Долгое время ресурсов более чем хватало. И вот в прошлом году после очередного апдейта нвидишных дров счастивая жизнь закончилась. Начались глюки, попытки откатиться (но дров нужных уже не нашлось), и в стремлении добиться работоспособости — обновление до последней LTS и переползание на xfce.
Даже года полтора назад если бы мне кто сказал, что машинка моя потребует переползания на xfce, я бы не поверил.
Нафига, если на ней 2 гига памяти и никакого особо прожорливого софта нет? Оказывается, хрен там — хорошо уже было. Ну, про это я уже не раз писал, а сейчас хотел поделиться последним экспериментом.

Есть evolution, который один умеет ходить к ms outlookup server за почтой.
Но сейчас он отказывается подключаться к серверам (любым), потому что якобы у него нет сети.
Сеть есть. Настроена статически и не через рабочий стол. Но evolution её почему-то не признает.
Год назад комп работал немного в другой сетевой конфигурации — в другой сети, на другом интерфейсе. В новую сетевую конфигурацию включал через второй интерфейс, с намерением когда-нибудь подключить первый обратно, но в процессе боданий выяснилось, что много кому не понравилось, что есть eth1, но нет eth0. Пришлось их свопнуть и всё заработало без нареканий. Почти. Вот только evolution этой сети не видит. Как будто это какая-то винда, в которой клиент привязался к конкретной карте, в конкретной конфигурации, через длинный идентификатор. Но в винде-то можно поковырять реестр, а тут-то что?
Ковыряние в логах, пытание с strace показало, что evolution сильно хочет связаться с dbus, но что-то там у него не срастается. Появилась версия, что именно через него он мог бы получить информацию о сетевой конфигурации. А раз не может подключиться, и не может получить конфигурацию (ну, так сделано, блин), значит и сети у него как бы нет.
Может потому что xfce? Вот для проверки и этой версии, решил зайти через Unity и там evolution запустить. Надежды никакой, тем более, в памяти какие-то следы остались что уже пытался подобное провернуть, но почему бы и не попробовать "на свежую голову"? Может мысли какие новые появятся.

Логинюсь через профиль с Unity. Как и ожидалось, памяти уже пожрано compiz под 200 мег, xorg около 120. Кстати, под xfcee памяти xorg потребляет только 79, компиза нет совсем, а а xfdesktop только 46.
Ну, да не за этим мы сюда пришли.
Запускаю evolution — тоже не видит сети. Попытался поконфигурировать сеть - не помогает. Выглядит так, будто бы это всё хозяйство рассчитано на подключение сети с декстопа, а у меня-же статика и прописано по-старому. Пободался, в общем, контролируя по htop съедаемую память. Так как при выедании свободной всё (под юнити) начинает глючить, падать и т.п. Но память ещё есть и можно не беспокоиться. Но надо бы какую-нибудь инфу погуглить. Но FF тоже в последнее время погрузнел и памяти жрёт как та свинья помои. Ну, думаю, запущу вместо него dillo. Запускаю…
…и это было последнее, что смогла запустить убунта… К счастью, - только в этой сессии.
На экране все иконка сразу выпали черезстрочкой, посреди навернулся медный таз нарисовался чёрный треугольник и всё.
С стороны по ssh не пускает - рефузит.
Семь бед — один ресет.

Загрузился. Естественно, в xfce. Решил поделиться - пишу. Чтобы освежить память запустил evolution через терминал. Вижу опять ругается на dbus — сокет не нашёл, зарегистрировать клиент не смог, и ещё какая-то фигня.
Запустился, а тут — батюшки мои! — уже не ругается что сети у него нет!
Уже и за почтой сходил, сволочь, и забрал что надо (и не надо было).
Значить, что-то правильное, всё-таки сделал. :) Ну, во первых, переключал профиль доступа к сети, во вторых, в юнитишной конфигурялке неиспользуемый (старый, бывший основной рабочий) отключи.
Видать мозги вправил.

Пока ещё не очень радуюсь, но заработал — это уже хорошо.
crower: (Default)
C полутора-гигениумом юникстайма, дорогие коллеги—программисты. Ну и будущим спейсианам тоже салют.
crower: (Default)
Жалуюсь.
В рамках проекта [personal profile] vitus_wagner по вычитке книги осознал, что для загрузки материала в mediawiki надо не совсем не то, что предоставляет finereader при "сохранении результата". Форматы есть всякие, но те, что дают разметку - это уже результат вёрстки с распознаванием. А для вычитки может понадобиться оригинал. Оригинал тоже предоставлен, но отдельно. И в исходном виде он имеет размер за три гига. Выгрузка в тексте - это результат распознавания без вёрстки. А для вычитки в медиавики нужен файл с исходными сканами, но подгруженным распознанным слоем, который движёк proofread подгрузит на страничку при первой вичитке страницы.
Значит что надо сделать?
Выгружаем из finereader-а в формате pdf. Это нам нужно для полного кайфа, так как там содержится не просто распознанный текст, но и разметка - где именно он на странице находится. Если честно, это нам нафиг потом не понадобится, но чисто для удовлетворения эстетического чувства, что всё сделано как положено, приятно.:)
С pdf работать не знаю как, но есть инструмент для работы с djvu. Там же есть конвертилка, запустив которую получаем djvu-формат.
Он нам нужен для извлечения текстового слоя в виде S-выражений:

(page 0 0 2600 3544
(line 552 2783 2186 3126
(word 552 2783 2186 3126 "LAMER"))
(line 953 2607 1743 2656
(word 953 2607 1134 2656 "Ouvrage")
(word 1154 2607 1287 2656 "publi\303\251")
(word 1311 2618 1400 2644 "sous")
(word 1422 2618 1460 2656 "la")
(word 1483 2618 1671 2656 "direction")
(word 1695 2618 1743 2656 "de"))
(line 914 2527 1793 2576
(word 914 2538 961 2575 "V.")
(word 988 2527 1286 2576 "Romanovsky,")
(word 1315 2538 1461 2576 "Claude")
(word 1483 2531 1793 2576 "Francis-Boeuf,"))
(line 1138 2447 1534 2495
(word 1138 2447 1305 2495 "Jacques")
(word 1342 2458 1534 2495 "Bourcart"))
(line 1185 673 1492 708
(word 1185 673 1348 707 "PARIS,")
(word 1399 678 1492 708 "1953")))


Следующий шаг — из исходных сканов надо получить те-же djvu.
Но сканы в png и такой конвертилки напрямую не попалось под руку, но есть другие.
К тому же есть сканы в color RGB, а есть в grayscale и один даже оказался почему-то в grya+alpha. Но последнее, думаю, просто недоразумение.
RGB переводим в jpg (например, тулзой convert от ImageMagick) и теперь c44 $src.jpg -slice 100 $dst.djvu
gray переводим (тоже convert) в pgm, а его, например, так: c44 $src.pgm -dpi 300 -percent 4 $dst.djvu
Параметры подглядел из своих старых записей и пока не внимательно не вникал зачем они и где сколько надо, на первое время они и не имеют решающего значния. В данном случае для серых сканов необходимо разрешение, достаточное для вычитки, а цветные так и вовсе не важны.
Проведя означенные операции со всеми сканами получаем постраничную djvu-кацию.
В них подгружаем текстовые слои, выуженные на предыдущем этапе из свёрстанного файнридером документа.
Далее собираем все страницы в мультибандл и "вуаля!" — можно загружать в mediawiki.
Я так и сделал. Файл, индекст, страница. Но в окне редактирования не обнаружил текста.
Расстроился. Что-то сделал не так? Но вроде эксперимент ставил, и подгруженный в документ текст извлекался.
Оказывается. У меня, вообще-то есть два mediawiki-сервера. И эксперимент я ставил на одном, а для вычитки загрузку собирался сделать на другом. И они разные. Там xenial, а там - precise. Но на последнем mediawiki как-то неудачно обновился, а на первом вслед за системой обновление прошло без особых проблем. В итоге на первом 1.29, а на втором - 1.25. Расширения ProofreadPage тоже разных версий. В пользу более старого, то что там специфичные элементы управления не сломались, а на новом их не видно.
Затаив дыхание заружаю файл туда где свежий софт — текстовый слой в наличии.
Значит, собрано всё верно.
А вот на обоих mediawiki кое-что сломалось. :)
crower: (Default)
Борьба увенчалась победой. Не сразу, и с какими-то дурацкими брыканиями.

У комодо стащил сертификат и бросил в /usr/share/ca-certificates/mozilla.
Вписал его в /etc/ca-certificates.conf.
Запустил update-ca-certificates — все, ок, говорит.
Запускаю wget — так же хрень.
Подсовываю сертификат напрямую — съедает и работает.
Зову на помощь strace — подсказывает, что wget ищет 8d28ae65.0.
Запускаю curl - та-же хрень. strace подсказывает, что curl ищет тот-же файл.
Делаю руками линк, на всякий случай апдейтилку — ок.
Запускаю wget — bingo!

В процессе бодания пытался и reconfigure делать, но в конце уже не трогал.
Вот и думаю — при очередном апдейте/апгрейде не потеряется ли эта хрень.
В записнушке пометку оставлю — в следующий раз полечу по-быстрому.
crower: (Default)
Отключение проверки сертификата — плохое решение и было всего лишь временным. Разобраться что там не так ещё предстоит.
Пока обнаружил, что среди установленных комодовских сертификатов есть только такие:

Subject: C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services
Subject: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO Certification Authority
Subject: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO ECC Certification Authority
Subject: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Certification Authority
Subject: C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=Secure Certificate Services
Subject: C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=Trusted Certificate Services

А сайт zniis в качестве центра авторизации кивает на:

/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA

Что, наверняка, совсем не одно и то-же.
crower: (Default)
Дай, думаю, погляжу чего это робот тихонечко так работает. Давно от него жалоб не было.
А оказыватеся с апреля сайт принудительно отправляет вопрошающего на https. Ладно, wget с этим справился сам и даже не жаловался:
--2017-04-27 05:24:31--  http://www.zniis.ru/bdpn/operators/router-table/
Подключение к proxy... соединение установлено.
Proxy-запрос отправлен. Ожидание ответа... 301 Moved Permanently
Адрес: https://zniis.ru/bdpn/operators/router-table/ [переход]
--2017-04-27 05:24:32--  https://zniis.ru/bdpn/operators/router-table/
Подключение к proxy... соединение установлено.
Proxy-запрос отправлен. Ожидание ответа... 200 OK
Длина: нет данных [text/html]
Сохранение в: «router-table»

     0K .......... .......... .......... .......... .......... 47,0K
    50K .......... .......... .......... .......... .......... 61,8K
   100K .......... .......... ...                               123K=2,1s

2017-04-27 05:24:35 (59,7 KB/s) - «router-table» сохранён [126072]


Но ровно через месяц случилась какая-то засада с сертификатом:

--2017-05-27 05:24:29--  http://www.zniis.ru/bdpn/operators/router-table/
Подключение к proxy... соединение установлено.
Proxy-запрос отправлен. Ожидание ответа... 301 Moved Permanently
Адрес: https://zniis.ru/bdpn/operators/router-table/ [переход]
--2017-05-27 05:24:30--  https://zniis.ru/bdpn/operators/router-table/
Подключение к proxy... соединение установлено.
ОШИБКА: невозможно проверить сертификат zniis.ru, выпущенный «/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA»:
  Невозможно локально проверить подлинность запрашивающего.
Для небезопасного подключения к zniis.ru используйте параметр «--no-check-certificate».


Увы, выгружающий скрипт писал "по быстрому", "на коленке", и обработку таких ошибок не закладывал. Поэтому с 27 мая все файлики-таблицы нулевого размера. В принципе, эта хрень никому явно и не нужна, а выгружается на всякий случай. Но вот вдруг такой случай возникнет, а у меня свежачка нет?
Добавляю --no-check-certificate, запускаю, но тут уже и "парсер" начинает кашлять и плеваться. Ну, думаю, ещё и внутри чего-то изменили. Начинаю разглядывать выгруженную страницу, а там хвоста нет. Заканчивается страница открытым div-ом, как будто что-то на сайте молчаливо сломалось.
Хм, думаю, и скармливаю урл validator.w3.org, но тот сразу нос воротит: 500 Can't connect to zniis.ru:443 (certificate verify failed)
Выходит, думаю, это не у меня какие-то косяки в технологии, а всё-таки на сайте.
Посмотрел хронологию: такая хрень появляется с 27 апреля - в самый раз как стали заворачивать на https.
«А ещё сайт ЦНИИС, называется!» ;)

PS. Парсинг придётся адаптировать.

UPD. Выяснил, почему с парсингом возникла проблема. С какого-то момента "там" решили, что слишком дофига таблиц в одном месте держать — не по феншую. Стали раскладывать по подпапкам. Названия подпапок с пробелами. Подпапки, да ещё и с пробелами в именах не были продусмотрены. :) "Адаптация" обошлась дешево — пришлось выпарсивать имена источника целиком и отдельно генерить локальное имя. Первое нужно для подкрузки недостающего, второе - для локального хранения. Так-то я их потом перекладываю в архив по подпапкам Архив/YYYY, а из-за того что у zniis старьё не удаляется, можно было либо скипать старое, либо проверять наличие и в архиве. Скрипт сделал лояльным и гибким — его устроит наличие файла где бы он не лежал.
Но по уму, конечно, надо переделывать залипуху на bash+grep+se+wget на нормальный скрипт. Например, на perl. Тем более, с libcurl руку немного набил, а остальные вещи делаются горазно гибче и проще.
crower: (Default)
UPD. Решил почистить лишнюю лирику и оставить самый навар.

WWW::Curl документирован слабовато и большей частью отсылает на сайт курловой документации.

Чтобы заюзать NTLM-авторизацюи надо сделать:

$curl->setopt(CURLOPT_HTTPAUTH, CURLAUTH_NTLM);


Для простого POST с передачей параметров в теле запроса не надо пользоваться WWW::Curl::Form, как можно было бы подумать, глядя в доку. Нужно:

$curl->setopt(CURLOPT_POSTFIELDS, $data);
$curl->setopt(CURLOPT_POSTFIELDSIZE, length($data));
$curl->setopt(CURLOPT_POST, 1);

Если использовать WWW::Curl::Form, то курл будет заворачивать каждый параметр в отдельный Content-Disposition. Соответственно, это и накладные расходы, и не факт что CGI умеет их отттуда извлекать.
Хотя, зачем вручную считать размер мне не понятно. Почему это не мог бы сделать сам курл?
crower: (Default)
Ура. Сегодня автоапдейтилка торрентов отработала в первый раз в полностью автоматическом режиме.
В прошлый раз она обнаружила обновлённый торрент, но не смогла его обновить по причине того, что старый линк на топик на форуме был прописан с протоколом http, а научена была обнаруживать https. Получилось по-дурацки смешно: "ой, торрент обновился! ой, нет, его апдейтить не умею".
А старых торрентов, которые ещё с реез создавались, дофига. Допилил: пофиг протокол, всегда использовать https на рутрекере. Потом её тестил — справилась. Но условия-то уже изменились. И хоть попытался максимально повторить исходную ситуацию (удалил новый торрент, запустил старый), но на форуме-то топик расспасибить уже не могу ;)
Хотя там, кстати, возникла и другая закавыка: содержимое быто изменено, что только запутало, потому что подумал что какие-то грабли всё-таки у меня.
Ну а в этот раз руки вообще не прикладывал.
Жаль только апдейт обнаруживается далеко не сразу. В прошлый раз реагирование произошло минут через десять, в этот — 33 минуты. Из-за того что трекер просит делать анонсы раз в час, до часу это запаздывание может доходить.
Поэтому с регулярно обновляемыми торрентами наваял супервизора, который раз в пять минут проверяет смену топика на форуме. Таких раздач у меня было штук шесть, а сейчас осталась только одна. Все серийные - фильмы и одна телепередача. Удобно мониторить не особо заморачиваясь, по титлу. Но если понадобится отслеживать что-то другого типа, придётся делать универсальную штуку: есть поле "зарегистрирован", старое запомнить и ждать когда обновится.
crower: (Default)
Вышел magnetico версии v0.5.0.
Наконец-то перестал регулярно падать с "Bad file descriptor".
Проблема, как и подозревал, была в попытке использования "протухших" соединения.
После этого кустарный мониторинг стал показывать, что количество открытых сокетов может увеличиваться и выше 500, чего раньше никогда не видел. Видел даже за тысячу. И не падал!
Зато стало попадаться предупреждение о какой-то недопустимой операции.
Не знаю, что меня сподвигло заглянуть в dmesg.
Увидел большое количество "nf_conntrack: table full, dropping packet" и траблшатинг пошёл по накатаной колее :)
Увеличил net.netfilter.nf_conntrack_max и net.nf_conntrack_max — сообщения в dmesg прекратили появляться и магнетико перестал жаловаться на недопустимую операцию.
Заодно обнаружил, что у краулера появились новые опции.
Включил дебаговую отладку и она мне понравилась.
Надо, наверно, сливать её в лог-файл, чтобы от не какой-нибудь прок был.
Не забыть бы только, :) а то с интенсивностью харвинга несколько десятков тысяч торрентов в сутки, размер лога может быстро выйти из под контроля. ;)
Ах, нет! ~ Xe4 торрентов в сутки это он собирал в предыдущие 6 дней (от 5 до 10), а вчера получилось около 130.
Параллельная мысль: вот только статистика слишком долго считается. Не сделать ли снапшот, как я для DPL недавно делал :)
И это при том, что сапгрейдил его вчера только часов около восьми вечера. Впрочем, может считалка статистики использует не локальное, а универсальное время, и тогда стахановский рывок получился не за 4 часа, а за 12. Ну, за сегодня и посмотрим, на сколько эффективнее стал процесс.
Плюс с базой стал шустро работать. Раньше после падения запускался долго, очень долго, несколько минут. Как-будто sqlite пытался почекать и/или восстановить базу после внезапно потерянного коннекта. А тут пришиб (чтобы лог прикрутить), запустил — и через 23 секунды появилось первое INFO Added. А судя по первому дебагу работу он начал уже через полторы секунды.
Удивило "Maximum number of neighbours now 1872" через 6 секунд. Неужто так быстро нахарвил? Потом количество уменшилось и теперь держится около 6½ сотен. fetch metadata task count сначала плавно добрался до четырёх с половиной сотен, а потом уменьшился. Иногда спускается ниже 300, но в основном держится около 3½ сотен.
И стал постоянно ругаться на "SybilNode operational error: `[Errno 22] Invalid argument`".
Пока ещё не выяснял что это за хрень.
Похоже, fetch metadata task соответствует количеству открытых сокотов. Можно от кустарного мониторинга отказываться. ;) Вот только tail -f log | grep word на логе в потоке работать не будет. Надо будет что-то сочинять.


UPD. Снапшот не понадобился. Заглянул в базу — там индекс только на хеш был. А статистика с распределением по дням строится с не индексированном полем. При полутора миллионах записей понятно что тормозить должно. Создал индекс — график стал отображатся через считанные секунды. Накладные расходы мизерные а удобство существенное. :)
crower: (Default)
Не смог решить загадку, как условия оной усложнились.

Вот уже который день необходимости в перезагрузке роутера не наблюдается. Пинги ходят надёжно, как в швейцарском банке. :)
Ладно если бы нагрузка упала. Так ведь наоборот, нагрузил железку. Опять запустил magnetico, и тот трудится непрерывно. В прошлый раз, кстати, он наоборот ускорял ухудшение связи, а тут — третьи сутки, как 20/20 пингов возвращаются.
Роутер? Но какой фактор мог повлиять? Разве что похолодало на улице в эти дни. Хотя дома на градуснике что рядом с компом как было 22-24. Хорошо, в следующий раз, если случится такая проблема, попробую поохлаждать. :)
Провайдер? Возможно. Помнится в прошлый раз, когда были проблемы, связанные с хреновой картой, симптомы были похожие. И техник говорил, что мой комп не закончив предыдущую сессию, начинал новую. А провайдерское оборудование, как я понимаю, трафик мне отправляло по обоим сессиям. Фича, что-ли, для лоадшаринга. Но одно дело если бы шнурка было два и это был реальный лоадшаринг, и совсем другое, если отправляемое по первой сессии/шнурку трафик уходит в никуда…
crower: (Default)
В последнее время с интернетом стала наблюдаться пакость. Поработает некоторое время и начинает подтормаживать.
С пол-года уже, наверно. Пускаю куда-нибудь пинг — пинги теряются.
Перегружаю tplink — всё опять работает как часы. В последнее время просто каждый день перегружаю точку доступа. За сутки тормоза практически не заметны, но на всякий случай, чтобы не запускать симптомы...
То ли провайдер мутит, то ли точка глючит. IP-адрес белый, но динамический и поэтому не знаю может ли какой-нибудь левый трафик душить пропускную способность. Хочется думать на провайдера, но в точке тоже не уверен. По крайней мере временами, когда наблюдаются сильные тормоза, даже до точки добраться бывает проблематично. Через локалку. То есть доступ к его интерфейсу совершенно не должен зависеть от wan. Если только через нагрузку. В самом начале инет включался прямо в мой комп и тогда можно было ещё чего-нибудь наснифить прямо на компе. А сейчас лениво что-то переделывать чисто для эксперимента. Эх, стар я стал. :)


А сегодня обнаружил ещё одно чудо. Перед перезагрузкой по привычке пускаю пинг, и по нему вижу когда точка перезагружается. И тут вдруг обращаю внимание, то до перезагрузки пинг был 68мс, а после — 74мс. Стабильно.
Раньше такого что-то не замечал.
crower: (Default)
Ох и люблю же я что-нибудь такое сделать, чтобы ничего не делать. :) Ну, почти ничего не делать. Т.с.
воспользоваться былыми результатами повторно. :)

Есть на станции такие файлы, в которые она сохраняет команды между дампами. Зовут их RELCMDHDF, если что.
Новые создаются при каждом дампе, старые становятся не нужными и если специально не пошевелиться, плодятся годами. Место поедают, конечно, но файлы, в общем-то, не большие. Впрочем, технология выделения дискового пространства там чуточку другая, из-за чего места занимать они могут гораздо больше, чем реально используют. Если станция не сильно старая, то проблема нехватки места может так и не наступить. Скорее станцию заменят. :D
Но вот в рамках эксплуатации могут возникать сложности. Работает там конструкция типа кластера и в случае смены активного узла происходит синхронизация дисков. Сначала будет попытка сделать быстрый апдейт - только того, что изменилось после того как узел находился в забытьи. Если не получилось и процесс затягивается, то происходит переключение на длинный апдейт, то есть тупая синхронизация всего подряд, чуть ли не по кластерам. И чем больше всяких файлов валяется, тем вероятнее переключение на длинный процесс. Поэтому много лет назад, приехавший настройщик, тяжело вздохнут собрался поудалять древние файлы. Хорошо что он ленился. Я тогда про них ещё ничего не знал, а как узнал какое богатство собираются удалять, спохватился и уговорил что сам всё сделаю. Товарищ, конечно, обрадовался, потому что автоматизировать рутинные операции не умел, а команд вводить пришлось бы долго. А тут ему предлагают ничего не делать, но работа при этом сделается. В итоге, файлы эти я скачал, и только после этого удалил те что надо. Потом уже сделал нужные настройки, чтобы станция сама эти файлы и через даталинк отправляла, и удаляла старые. В результате получил архив вносившихся в станционные данные изменений. Зачем? Очень удобно отыскивать когда нечто делалось. Например, возникает вопрос: имеется странный маршрут, зачем и почему он сделан таким? Идеальным был бы электронный журнал, хоть и требовал бы дополнительных телодвижений на протоколирование всего подряд. Но начиналась эта работа слишком давно. Есть два шкафа толстых папок распоряжений, по которым эти изменения вносились. Но когда? И вот тут на помощь приходит RELCMDHDF.
Долгое время пользовался простым grep-ом. Потом прикрутил врапер для удобства. Со временем к враперу прикрутил отыскивание по TRLOG1FILE, в который вообще все диалоги со станцией пишу. Собирался было прикрутить скрипт на веб-страницу, но задумался … и решил, что нужно грузить всё это в БД. Глаза боятся, а руки делают.
В результате получил возможность быстрого поиска, удобного доступа (и не только мне), и сводной таблицы.
Сотрудники тоже оценили фичу. Теперь даже непонятно как можно было без этого обходиться. :)

И вот ещё одна станция оказалась под рукой. Всё ходил вокруг неё, облизывался. Вот только в отличие от нашей, доступа к даталинку нет. А без него файлы качать только через IOFAT. А это не совсем файлы. Точнее, чтобы получить оригинал, нужно его обработать. Старые командники оттуда таким образом я уже давно вытащил. Нужное искал обычным грепом, но это же оскорбляет эстетическое чувство. И вот вчера наконец набросал конвертилку из IOFAT в оригинальные файлики. Таблицы в базе, оказывается, я уже давно сделал и даже скрипты готовы. Так что осталось это дело только загрузить. Класс! Теперь только нюансы отлаживаю. То командные строки оказываются чрезмерно длинные. То внутриблочные счётчики команд решил вернуть.

В общем, сделал один раз, а удовольствие приносит многократно.
crower: (Default)

С оптимизацией получился облом.

Напомню, что была попытка соптимизировать запрос с select ... where date(field) in (...) group by .... Я в курсе, что конструкция field in (...) сама по себе дорогая, но вполне приемлема, если потеря скорости незначительна, а альтернатива может оказаться ещё дороже.

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

Попробовал другое "дешёвое" решение — внедрить ограничение диапазона, где код where date(field)≥{min_time} and date(field)<{max_time} призван был сократить первоначальную выборку, и уже после этого работал бы var in (...). Нужно было планчик составить, но лениво. А потом оказалось что и var in лишний. С выборкой нужных дат в самом скрипте всё оказалась гораздо быстрее. И поначалу всё заработало как надо. И дело даже не в кешировании. Потому как регулярно, раз в час поступают новые данные.

Эффект был кажущимся из-за того, что на момент тестирования дат было не так много и group by на все эти даты не сильно тормозил. Но наступление события "С", ради которого весь этот сыр-бор, задержалось. И получилось что между первой и последней датой времени прошло настолько много, что быстродействие от экономии на отказе от var in полностью пожралось group by. Долгим и бессмысленным.

Ещё бы:

  • 4 таблицы: 1.2млн, 1.3млн, 26млн и 27млн записей.
  • интересующие данные (без уточнения по дате) составляют 64К, 10К, 130К и 20К записей.
  • в таблицах сидит timestamp, а выборку и результат нужно делать от функции по нему. Хоть через substr, хоть по date.

Можно было плюнуть и вернуться к старой схеме, но "мы не привыкли отступать"© и это оскорбляет эстетическое чувство.

Поэтому пришлось делать красиво и по-полной схеме. При обращении к странице, скрипт запрашивает данные, уже сгруппированные по дате и лежащие в специальной дочерней таблице. Если на определённую дату данных нет, то запрашиваются данные в родительской таблице. Если они оказываются полными за указанную дату (24 часа, 1440 минут или 86400 минут), то они вставляются в дочернюю таблицу и в следующий раз будут извлекаться оттуда. Считать их заново будет не нужно. Операция сия была необходима для одного определённого объекта, так что пухнуть дочерние таблицы не будут. При периодическом опросе данные за прошедшие дни обстчитываются постепенно, и только за текущий - постойнно. В результате подтормаживание составляет при пересчёте прошедших суток считанные доли секунды, а за текущую дату - даже не заметно. Всё-таки выборка по timestamp ≥ {time} and (timestamp < {time} + INTERVAL 1 DAY) гораздо быстрее, чем упоминавшиеся ранее конструкции. Да и group by нужно будет убрать, т.к. алгоритм и ткак каждый раз выдёргивает по одной строке.

Зато теперь всё классно. :)

crower: (Default)
Спасибо Виктории.


обидеть Таню может каждый,
не каждый может убежать
----
ищу приличную работу,
но чтоб не связана с трудом
----
Read more... )
crower: (Default)
…весь тот катаклизьм в ЖЖ, принял решение сворачивать там манатки:
1. Перестать кросспостить посты отсюда туда.
2. Поудалять тамошние посты, благо всё уже импортировано в дрим.
3. Свести тамошнюю активность до минимума.
Будет хуже там — больше народа станет перебираться в т.ч. сюда.
crower: (Default)
Знал я что where field in (…) — довольно дорогая конструкция, но чтобы на столько!
Иногда приходится её использовать в тех случаях, когда расходы на неё совсем небольшие, а методы обхода оказываются гораздо дороже.
Была старая задача, которая генерировала сводку по нескольким таблицам. В таблицах — результаты работы измерительных программ по изменению нагрузки. Ключевые параметры — дата/время, период, объект измерения. Данные собираются по 5, 15, или часовым интервалам. И тут нужно нарисовать табличку: колонка - дата, строка - параметр. Диапазон дат — до месяца, но не подряд, а выборочно. Вот тут-то и корячится where date in (date1, …, dateN). Свинство в том, что поля date нет, а есть datetime, то есть timestamp. А значит нужно делать или date(datetime), или substr(datetime, 1, N) в тех случаях, когда группировка по другим критериям. А это тоже накладно. Потом ещё будет group by по этому полю. Но where вырастает в date(datetime) in (…) и работает, соответственно, гораааздо дольше. Пока табличка была маленькая, всё работало довольно шустро. Но вот данных за год нападало уже на 23 миллиона и запрос стал выбираться несколько секунд. А это неприятно. Пришлось брать из загашников бубен. ;)
Первым делом попытался ограничить область поиска дополнительным условием. Т.е. минимальная и максимальная даты определяют вилку, за пределами которой можно ничего не искать.
Не помогло.
Без особой надежды решил убрать in (…) вообще, благо алгоритм обработки получаемых данных был построен так, что заполнял таблицу только нужными датами, а поправить нужно было только подсчёт итоговых значений, что делается одной строчкой.
Запускаю — и удивляюсь. Вместо нескольких секунд запрос стал выполняться доли секунды.
И это при том, что из-за group by калькуляция в запросе вынуждена выполняться над лишними датами!
Ладно, думаю. Может этот период просто незаполнен и пока ещё нечего считать? Делаю запрос за прошлый год и картина почти такая-же. Значит на самом деле 8*SUM+2AVG за 20 дней (по 288 измерений) выполняется гораздо быстрее, чем то же самое с IN (date1..date20).
«Вот что крест животворящий делает»©
crower: (Default)
Удивительно, но сегодня приложение запустилось, спросило хочу ли я подключиться к идущей сессии только 1 раз и ни разу не предложило купить расширенную версию.
Но за время гонки оно один раз просто упало, а когда я на втором экране попытался поменять колонку лучшего времени на интервалы, зависло. И так три раза при трёх запусках подряд. После чего я уже не стал искушать судьбу, и ограничивался просмотром первого экрана.
А результат…
Доволен что Сэб обошёл Льюиса.
Не рад что Даня финишировал позади Карлоса. Хотя информация в начале гонки об отказе КЕРСа обещала ещё более худшим исходом. Но задумался — лучше бы не просили Сайнса пропускать Даню. Так была бы надежда обойти его своими силами и не требовалось бы уступать при неуспехе обгона Чеко.
А так-то, в общем-то, на плохо. И жаль, что БК не удержался за Даней. Мелочь, а было бы приятно.
crower: (Default)
«Эх, были времена»© — на разных сайтах можно было спокойно найты повремёнку гонки. В онлайне.
Потом этих мест становилось всё меньше. На f1news.ru нашёл текстовую трансляцию и было не плохо.
Потом нашёл ещё и спортбокс. Особое удовольствие было в том, что без рекламы.
Повремёнку стал смотреть на сайте Ф1. Вроде ничё так, но клиет слишком тяжёлый.
Потом обнаружил нативного (!) под линукс (!) клиента - текстового(!!!). Юзал он тот же канал что и ф1-повремёнка. И было счастье.
Ещё оно добавлось после того, как обнаружил канал Sky Sport F1 через torrent-TV. С нашлёпкой на VLC.
И вот это был кайф, ибо в разных окнах были трансляция в спортбоксе, скайспорт, текстовая трансляция с f1news.rum, повремёнка текстовая либо на крайний случай тяжёлая в браузере, и карта трассы.
«Та не довго сонце гріло, не довго світило…» ©
Началось «западло» с того, что Берни со товарищи стал жадничать и с повремёнки пропали времена по секторам.
Потом пропал старый лёгкий интерфейс и появился толстый тяжёлый, через ещё какую-то хрень, которая работать не хотела.
Тут появилось приложение для андроида и я стал смотреть ливтайм там.
Потом перестал работать торрент-тв.
Потом какая-то жопа стала со спортбоксом.
В приложении, кстати, время на секторах тоже пропало.
Как ни странно, появилось предложение платить денежки и под этот шумок из фриварной версии пропало много и других фич.
В прошлом году цена на ф1аксэс выросла сразу втрое. Берни совсем совесть потерял. Покупать уже не стал.
После пары обновлений эта дура стала глюкавой, как не знаю что. Она стала виснуть. И чем дальше, тем чаще.
А как минимум, между годами не апгрейдиться нельзя, потому что на новый сезон расписание ему нужно.
И вот наконец сегодя первая квала сезона. Запускаю приложение. Предупреждает, как обычно — идёт трансляция, хотите присоедениться? Ясен пень! А зачем я его запускаю. И тут-же предлагает сапгрейдиться до про-версии, чтобы все фичи смотреть. Вот только вываливется в последнее время почему-то по две пары эих окошек. Да, нет, да, нет. В прошлом году после этого подключалась. А тут просит емейл, появляется клава, начинаю вводить... а поля-то ввода ничерта не видно - клавой закрыло. После нескольких попыток умудряюсь изловчиться, да только без толку, так как приложение вусмерть зависло. Если поторопиться, можно успеть несколько букв емейла ввести, до того как эта дура зависнет. А можно не вводить — всё равно зависнет. Пробовал переустанавливать — не помогло.
В общем, убили хорошие вещи.
Теперь остаётся только тупо пялиться в ТВ и текстовую трансляцию смотерть.
crower: (Default)
Вот некоторые одарённые компании любят у себя писать "Техподдержка 24x7x365". Это значит, что они 29 февраля не работают? ;)
Зачем писать 365, если из 7 это и так следует?
И вообще, если написано "круглосуточно", то это должно значить и 7, и 365, и 366, и т.д.
Да, понимаю — просто маркетинговый ход. :) Расчитано на идиотов? Придумано идиотами? В лучшем случае и те и другие играют идиотов. В худшем — идиотов играют идиоты.
Точно, как сейчас модно:

И4©

crower: (Default)
После обновления с 12.04 до 16.04 на комп стало невозможно зайти по ssh со старого trustix.
Жаловался, что "no matching cipher found: client aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc@lysator.liu.se server chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com".
Не иначе как в борьбе за защищённость соединений отключили более слабые алгоритмы. Времени заняться сразу не было, и на время стал ходить с citrix в обход - через 12.04. Новые алгоритмы он знает, а старые у него не выключали.
Наконец дошли руки это дело полечить.
В итоге получилось довольно просто. В sshd_config добавил: "Ciphers +aes128-cbc". Пока разбирался с синтаксисом и мелочами "за компанию" добавил "Macs +hmac-sha1".
Клиент сменил тональность брани на "no kex alg".
Погуглил, нашёл совет, добавил "KexAlgorithms diffie-hellman-group1-sha1", после чего всё заработало.
Бинго.
А то я уже начал переживать, что придётся транзитный сервак оставлять как 12.04. Впрочем, пока его действительно нельзя трогать, потому что кое-какие важные проги (к сожалению, не opensource) на 16.04 глючат. На 12.04, кстати, тоже немного глючат, но по крайней мере использовать их это не мешает.

Profile

crower: (Default)
crower

July 2017

S M T W T F S
      1
23 45678
910111213 1415
161718 19202122
23242526272829
3031     

Syndicate

RSS Atom

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 22nd, 2017 12:35 pm
Powered by Dreamwidth Studios