The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Раздел полезных советов: Решение проблем с удалением файлов ..., auto_tips (??), 01-Сен-09, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


7. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от cvsup (ok), 01-Сен-09, 15:25 
На 7ТБ? база данных чего?
Ответить | Правка | Наверх | Cообщить модератору

15. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от pavlinux (ok), 01-Сен-09, 16:40 
>На 7ТБ? база данных чего?

http://community.livejournal.com/ru_linux/2289534.html
> PS. Предвосхищая вопросы. Железка это многоузловой промконтроллер, управляющих огромным
> (450 тыс. тонн) газохранилищем. В связи с событиями на СШ ГЭС, начальством было
> приказано debuglevel увеличить на 2 пункта (условно с 1 до 4 при максимальном 6).
> Если раньше 7Тб эти набегали в лучшем случае за 50-60 суток, то сейчас эти 7 Тб
> заполняются за 18-20 часов.

Ответить | Правка | Наверх | Cообщить модератору

28. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от Karbofos (??), 02-Сен-09, 01:03 
фигасе, и это все дело одним файлом? в принципе, объясняет многое уровень русского языка у того коллеги. совсем плохо, если он живет в России. уровень языков программирования, надеюсь, у него выше...
оттого и бешеные проблемы преодолением трудностей, которые создали себе сами. дебаг-инфу можно создавать и в компактной форме, вплоть до битовой кодировки. а дальше уже и на лету компримировать и прочее, если мощности позволяют.
да, конечно, зависит от "запущенности" софта
Ответить | Правка | Наверх | Cообщить модератору

33. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от Анонумоис (?), 02-Сен-09, 01:44 
>объясняет многое уровень русского языка у того коллеги.

Уровень русского языка ничего не объясняет, он же не поэт и не писатель?
Объясняет все "Конфиг Core2Quad 6600/8 Гиг ECC/i3000 Некий java софт от большой технологической железки пишет огромный файл до 7 Тб".

Выводов несколько. Софт писали недавно, оборудование закупили недавно, писали на java, но не в этом дело, еще дело в "технологической железке", которая генерирует файлы по 7ТБ за сутки.

Что бы они делали десять лет назад (в 1999), покупали бы CRAY? Там внутри явно проблемы с оптимизацией, т.к. сейчас, куда не плюнь, практически все данные передаются/хранятся в сжатом виде и сжимаются по многу десятков раз (ethernet/SDH/PCI express/DOCx/PDF/JPG/MP3/FLAC/MP4...). Только сжимаются они не в ZIP архив 7ТБ базу, а на том уровне, на котором проще всего её осмыслить. Как минимум в голову приходит PNG.

Ответить | Правка | Наверх | Cообщить модератору

34. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от Karbofos (??), 02-Сен-09, 01:57 
основная проблема это "Некий java софт"? проверить, не так уж и сложно, экспериментируя с меньшими размерами файла проверять элементарно в top, что происходит. есть и другие подручные средства линукс
Ответить | Правка | Наверх | Cообщить модератору

35. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от Анонумоис (?), 02-Сен-09, 01:57 
>Как минимум в голову приходит PNG.

Это если данные от датчиков поступают в бинарном виде. Если это лог, то сжимать его еще проще, т.к. 90%(из головы взял) данных одинаковые. Ну не верю я, что датчик выдает каждую секунду разные данные + штамп времени, там меняется всего 1,2,3 бита! Идентификатор датчика не меняется вовсе. Есть преобразования Фурье, есть, да чего только нет... Было бы желание.

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

36. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от Анонумоис (?), 02-Сен-09, 02:05 
>Далее этот файл сжимается зипом до приемлимых размеров (до 200-400 Гб)

Полный звездец! Значит база легко может весить 200-400Гб сама по себе. А если применять специальные методы (выше написал, что сразу пришло в голову), реальный размер этой базы - сотни мегабайт и даже мегабайты!

На таком железе данные из LOG'а извлекутся мгновенно, а вот из 7ТБ базы в ZIP на ленте - ПОЛНЫЙ ЗВЕЗДЕЦ!

Ответить | Правка | Наверх | Cообщить модератору

39. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от Админ Веня (?), 02-Сен-09, 09:23 
Разрабатывали систему, меньшего масштаба, для "мобильных "электростанций. При условий что датчиков от 50 до 500, при постоянной работе двигателей, и без усреднения данных(т.е. данные пишутся примерно от 10000 в секунду), база занимала за 3 месяца около 40 гиг.
база мускул (ембедед), 2гига память. решение используется уже на нескольких десятках объектов в течении 4х лет
Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

44. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от Анонумоис (?), 02-Сен-09, 12:53 
>база мускул

MySQL - база данных специально для критически важных объектов, а вот 5 формул из 2 курса любого вуза применить - все, сломается все критическая надежность, этого же нельзя допустить!

Еще раз говорю, даже процессор без злых алгоритмов + алгоритмов самопроверки и т.д. не работает. Почему нельзя записывать показания датчиков в "сжатом" виде? Неужели у нас нет на это ГОСТов? Как записывали показания датчиков до 1998 года?

Зачем записывать в MySQL (где тоже могут быть ошибки) базу явно одни и те же цифИри? Чтобы отвязались? Мы вот мол логи пишем, если чего, это не мы.

Ответить | Правка | Наверх | Cообщить модератору

104. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от Админ Веня (?), 05-Сен-09, 23:09 
Таки нет, цифры разные при старте двигателей и во время работы оного. не синхронные они.
следить нужно.
а мускул почему... чем заменить можно, легковесным и "интеллектуальным"?
Ответить | Правка | Наверх | Cообщить модератору

106. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от aborland (?), 05-Сен-09, 23:52 
>Таки нет, цифры разные при старте двигателей и во время работы оного.
>не синхронные они.
>следить нужно.
>а мускул почему... чем заменить можно, легковесным и "интеллектуальным"?

Дык и на интербейз посмотреть можно и на sqlite
и даж свое ченить на коленке слабать

Ответить | Правка | Наверх | Cообщить модератору

107. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от Админ Веня (?), 06-Сен-09, 12:57 
_СТАВИТЬ_ сервер баз данных для этого???
у нас "мускул ембедед"
Ответить | Правка | Наверх | Cообщить модератору

37. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от Karbofos (??), 02-Сен-09, 02:17 
> Уровень русского языка ничего не объясняет, он же не поэт и не писатель?

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

но, с русским языком я могу и заблуждаться. :)

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

38. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от Pilat (ok), 02-Сен-09, 02:22 
>> Уровень русского языка ничего не объясняет, он же не поэт и не писатель?
>
>часто показывает на уровень образования. к примеру, мне тут один птушник пыталя
>давеча доказать, что логические и битовые операции - вещи идентичные.
>
>но, с русским языком я могу и заблуждаться. :)

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

Ответить | Правка | Наверх | Cообщить модератору

42. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от Karbofos (??), 02-Сен-09, 10:08 
если бы я конкретно пощупал систему, на которой этот гемор происходит, где допустили ТАКОГО рода раздолбайство с протоколированием на некоем ява софте... а так, кроме общих рекомендаций по поиску причин зависонов, которых аффтар явно не знает, аки простые методы диагностирования, нечего и сказать. а если и скажу, так аффтар этого, скорее, не поймет.
так что лично Вы можете быть в замешательстве от каждой буквы, написанной мной. если уж так сильно хотите. io wait тоже вызывает недоумение?
Ответить | Правка | Наверх | Cообщить модератору

67. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от pavlinux (ok), 03-Сен-09, 02:48 
Вы об каких логических операциях говорите, в формальной логике или в математической?

И можно повторить то место, в котором ПТУшнег с вами наконец согласился.


  

Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

74. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от Karbofos (??), 03-Сен-09, 17:35 
он утверждал, что

(boolTest1 ^ boolTest2) // boolTest1, boolTest2 are bool

одно и тоже с

(int32x1 ^ int32x2) // int32x1 int32x2 are integer

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

Ответить | Правка | Наверх | Cообщить модератору

52. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от Iv945n (ok), 02-Сен-09, 18:25 
> Как минимум в голову приходит PNG.

Чо? Газохранилище генерирует картинки (фотографии газа? :-)) ) и сохраняет их в базу (нафига? учили же что лучше в файловой системе картинки хранить).

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

54. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от Анонумоис (?), 02-Сен-09, 20:41 
Да, Karbofos оказался прав.

>учили же что лучше в файловой системе картинки хранить

А меня учили базы данных хранить в RAW разделах.

>Газохранилище генерирует картинки

В чем принципиальное отличие битовой последовательности, генерируемой некой "большой технологической железкой" от изображений/звука? PNG, FLAC и LZMA - очень стройные примеры того, как можно осознанно, эффективно и без потерь сжать битовую последовательность.

Ответить | Правка | Наверх | Cообщить модератору

56. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от Iv945n (ok), 02-Сен-09, 21:11 
>>учили же что лучше в файловой системе картинки хранить
>А меня учили базы данных хранить в RAW разделах.

Оффтопик, речь о файловых системах. И что мешает завести под блобы отдельный раздел с подходящей файловой системой?

>>Газохранилище генерирует картинки
>В чем принципиальное отличие битовой последовательности, генерируемой некой "большой технологической железкой" от
>изображений/звука? PNG, FLAC и LZMA - очень стройные примеры того, как
>можно осознанно, эффективно и без потерь сжать битовую последовательность.

Ну какбэ мне думалось что PNG и FLAC таки некоторым образом рассчитаны именно на графику и звук соответственно, иначе бы жали и графику во FLAC и музыку в PNG.

Ответить | Правка | Наверх | Cообщить модератору

94. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от Анонумоис (?), 04-Сен-09, 05:05 
>Оффтопик, речь о файловых системах.

Честно говоря, я совсем не понял о чем речь в данной статье. Какие-то mysql базы невероятного размера на нестабильной версии файловой системы...

>Ну какбэ мне думалось что PNG и FLAC таки некоторым образом рассчитаны
>именно на графику и звук соответственно, иначе бы жали и графику
>во FLAC и музыку в PNG.

Может я изъясняюсь непонятно... Мне показалась странной база в 7ТБ, которую каждые пол дня пытаются удалить... Вот я и предположил, что по аналогии с музыкой и звуком можно и эту информацию как нибудь сжать.

Ответить | Правка | Наверх | Cообщить модератору

102. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от нер (?), 05-Сен-09, 15:48 
> Уровень русского языка ничего не объясняет

Заблуждение. Невозможно много читать и не знать языка. Плохой русский - мало читал. Какой он тогда, к жукам майским, специалист, если он за всю жизнь 3 книги прочёл? Под хвост сразу таких гнать надо с таких проектов. Понимаете?

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

43. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от lora (?), 02-Сен-09, 12:02 
А что не так с русским языком у автора того топика на ЖЖ?
Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру