Проблема при работе с большими файлами (~ 5 Гб)
- Author
- Message
-
Offline
- Posts: 15
- Joined: Wed Dec 08, 2010 9:47 am
Проблема при работе с большими файлами (~ 5 Гб)
Доброго времени суток.
Есть задача - обрабатывать очень большие файлы, размером порядка 5 Гб.
Файлы - текстовые, внутри файлов разметка xml.
При открытии такого файла с помощью AkelPAd происходит следующее:
редактор AkelPad открыл 1/10 часть файла и пипец.
Ни ошибок, ни варнингов - просто показывает одну десятую от начала файла и всё.
В исходном файле 60240535 (60 с лишним млн) строк, а АкельПад показал 6343812 (6 с лишним млн строк).
Для проверки сделал "Сохранить как" и сохранил открытый файл с другим именем - размер сохраненного файла примерно в 10 раз меньше исходного.
В описании AkelPad на заглавной странице написано "вообще, размер редактируемого файла теоретически не ограничен".
Хотелось бы понять в чем проблема и можно ли использовать AkelPad для моих задач.
Ибо редактор в остальном - просто отличный, пользуюсь им давно и с удовольствием.
Есть задача - обрабатывать очень большие файлы, размером порядка 5 Гб.
Файлы - текстовые, внутри файлов разметка xml.
При открытии такого файла с помощью AkelPAd происходит следующее:
редактор AkelPad открыл 1/10 часть файла и пипец.
Ни ошибок, ни варнингов - просто показывает одну десятую от начала файла и всё.
В исходном файле 60240535 (60 с лишним млн) строк, а АкельПад показал 6343812 (6 с лишним млн строк).
Для проверки сделал "Сохранить как" и сохранил открытый файл с другим именем - размер сохраненного файла примерно в 10 раз меньше исходного.
В описании AkelPad на заглавной странице написано "вообще, размер редактируемого файла теоретически не ограничен".
Хотелось бы понять в чем проблема и можно ли использовать AkelPad для моих задач.
Ибо редактор в остальном - просто отличный, пользуюсь им давно и с удовольствием.
-
Offline
- Site Admin
- Posts: 6311
- Joined: Thu Jul 06, 2006 7:20 am
Goodvin
Странно почему ошибок не было, возможно из-за недостатка ресурсов. Для комфортного редактирования файла в AkelPad'е, размер свободной оперативной памяти должен быть примерно в три раза больше размера файла. Т.е. в вашем случае примерно 15Гб.
Пишут, что EmEditor, UltraEdit справляются в таких случаях.
Странно почему ошибок не было, возможно из-за недостатка ресурсов. Для комфортного редактирования файла в AkelPad'е, размер свободной оперативной памяти должен быть примерно в три раза больше размера файла. Т.е. в вашем случае примерно 15Гб.
Пишут, что EmEditor, UltraEdit справляются в таких случаях.
-
Offline
- Posts: 2247
- Joined: Tue Aug 07, 2007 2:03 pm
- Location: Vinnitsa, Ukraine
А если учесть что мы работаем в WIN32 то саксимальное количество доступной нам виртуалки - ну в крайнем случае 3GB(и то если редактор перестроить со специальным флажком, а так только 2GB), то и размер файла ограничивается макс 1Гб.Т.е. в вашем случае примерно 15Гб.
Скорее всего читают порциями.Пишут, что EmEditor, UltraEdit справляются в таких случаях.
Instructor, какими-нибудь стресс-утилитами пробовали гонять АкелПад?
-
Offline
- Posts: 15
- Joined: Wed Dec 08, 2010 9:47 am
Другие программы, из числа мной опробованных, при невозможности выполнить задачу - выдают варнинги и/или эксепшены на тему. AkelPad ничего не выдаёт, он исправно работает, в нём можно делать поиск и автозамены, но оперирует он десятой частью файла - порядка 480 мегабайт.Instructor wrote:Goodvin
Странно почему ошибок не было, возможно из-за недостатка ресурсов.
Я запускаю эту задачу на машине с 16 ядрами CPU и 64 Гб ОЗУ.Instructor wrote:Для комфортного редактирования файла в AkelPad'е, размер свободной оперативной памяти должен быть примерно в три раза больше размера файла. Т.е. в вашем случае примерно 15Гб.
ОС - Win Server 2003 64-битный.
Ресурсов там более чем достаточно.
EmEditor справляется, да.Instructor wrote: Пишут, что EmEditor, UltraEdit справляются в таких случаях.
Но он платный и проприетарный.
А мне бы решение опенсорное, на то есть ряд причин.
-
Offline
- Posts: 15
- Joined: Wed Dec 08, 2010 9:47 am
Винда у меня 64-разрядная, серверная.FeyFre wrote:А если учесть что мы работаем в WIN32 то саксимальное количество доступной нам виртуалки - ну в крайнем случае 3GB(и то если редактор перестроить со специальным флажком, а так только 2GB), то и размер файла ограничивается макс 1Гб.Т.е. в вашем случае примерно 15Гб.
И оперирует AkelPad куском файла размером около 480 Гб.
Непохоже.FeyFre wrote:Скорее всего читают порциями.Пишут, что EmEditor, UltraEdit справляются в таких случаях.
EmEditor несколько минут считывает файл, притом размещает его точно не в ОЗУ, а похоже что как-то индексирует.
После считывания EmEditor жонглирует этим 5-гиговым файлом быстро и легко, моментально скроллит, быстро делает поиск, позволяет легко перейти в люое место при количестве строк более 60 миллионов.
Как они это делают - не знаю, исходников не дают.
-
Offline
- Posts: 876
- Joined: Tue Jul 24, 2007 8:54 am
А толку-то, Акель же все равно 32 разрядный.Винда у меня 64-разрядная, серверная.
Вообще с большими файлами порой тоже сталкиваюсь. Пока что Акель при считывании файла подвисает, пока не прочитает его весь (и не перегонит весь текст в utf16, насколько я понимаю). Можно только отменить чтение. А хотелось бы, чтоб некоторый функционал был доступен уже после обработки первых страниц файла - примерно так, как делает MS word. Пусть будет read-only и без статистики по строкам, но хотя бы чтоб просмотреть начало можно было. Даже если этой фичи не будет, все равно будет разумно перегонять текст из кодировки в кодировку не одним большим куском, а блоками поменьше, что существенно сократит потребление оперативки.
Goodvin
а какого рода обработка требуется?
-
Offline
- Posts: 2247
- Joined: Tue Aug 07, 2007 2:03 pm
- Location: Vinnitsa, Ukraine
Ну тут Вам в помощь lister32.exe (Просмотрщик от Total Commander-а отдельным приложением).Пусть будет read-only и без статистики по строкам, но хотя бы чтоб просмотреть начало можно было.
Как сказал Fr0sT, Акел остается 32 разрядным, и как сказал я, если Акел будет специальным образом скомпилирован, то максимум он получит 3ГБ памяти.Винда у меня 64-разрядная, серверная.
И оперирует AkelPad куском файла размером около 480 Гб.
Всплывет проблема разрезания на блоки: где бы это так разрезать файл, что-бы не разрезать пополам мультибайтный символ. Для перекодировок отдельно существует iconvДаже если этой фичи не будет, все равно будет разумно перегонять текст из кодировки в кодировку не одним большим куском, а блоками поменьше, что существенно сократит потребление оперативки.
-
Offline
- Posts: 15
- Joined: Wed Dec 08, 2010 9:47 am
EmEditor тоже 32-рязрядный - а работает без проблем на такой задаче.Fr0sT wrote:А толку-то, Акель же все равно 32 разрядный.Винда у меня 64-разрядная, серверная.
Хотелось бы, чтобы и AkelPad позволял его использовать так же.
Искать в файле строки, как уникальные, так и многократно встречающиеся, делать автозамену определенной подстроки во всем файле и т.п.Fr0sT wrote:Goodvin
а какого рода обработка требуется?
-
Offline
- Posts: 15
- Joined: Wed Dec 08, 2010 9:47 am
Сразу после открытия файла процесс AkelPad отъедает 990 мегабайт с копейками.Instructor wrote:GoodvinА сколько памяти, то он отъедает?...но оперирует он десятой частью файла - порядка 480 мегабайт.
Потом, через полчаса занятая процессом память может уменьшиться до 4 мегабайт.
Я так понимаю, это его винда складывает в своп.
-
Offline
- Posts: 2247
- Joined: Tue Aug 07, 2007 2:03 pm
- Location: Vinnitsa, Ukraine
Ну вместо с 6 студией когда-то была такая утилита Stress, можно было настроить как часто нагружать процессы системными запросами: запросы на перерисовку окон, пару десятков других системных сообщений; дальше, можно было настроить, сколько памяти забрать у процесса, файловый ввод-вывод(временные файлы дергает), по-моему могла даже в контексте процесса создавать собственные потоки. Я если честно, её сейчас найти не могу.
В современных WindowsSDK есть Microsoft Application Verifier (можно стянуть отдельно). В принципе задачи те же выполняет, но естественно меньше настроек и удобств(такая тенденция у мелкомягких).
Можно ещё через статические анализаторами кода прогнать исходники.
В современных WindowsSDK есть Microsoft Application Verifier (можно стянуть отдельно). В принципе задачи те же выполняет, но естественно меньше настроек и удобств(такая тенденция у мелкомягких).
Можно ещё через статические анализаторами кода прогнать исходники.
-
Offline
- Posts: 15
- Joined: Wed Dec 08, 2010 9:47 am
Уважаемые разработчики, сообщите, пожалуйста, есть ли в принципе интерес к решению возникшей у меня проблемы?
Есть мнение, было бы очень хорошо, если бы AkelPad стал фактически единственным свободным и открытым текстовым редактором, способным работать с такими большими файлами.
Потому как ни один из перепробованных мной - не справился.
А перепробовал я их около двух десятков, перебрал все известные мне свободные и просто фриварные проекты, в том числе windows-порты юниксовых/линуксовых редакторов.
Ближе всех к решению именно AkelPad, вот если бы только помочь ему открывать весь файл, а не десятую часть.
Может быть я смогу чем-то помочь?
Предоставить какие-либо логи, дампы или какие-то еще сведения.
Есть мнение, было бы очень хорошо, если бы AkelPad стал фактически единственным свободным и открытым текстовым редактором, способным работать с такими большими файлами.
Потому как ни один из перепробованных мной - не справился.
А перепробовал я их около двух десятков, перебрал все известные мне свободные и просто фриварные проекты, в том числе windows-порты юниксовых/линуксовых редакторов.
Ближе всех к решению именно AkelPad, вот если бы только помочь ему открывать весь файл, а не десятую часть.
Может быть я смогу чем-то помочь?
Предоставить какие-либо логи, дампы или какие-то еще сведения.
Last edited by Goodvin on Thu Dec 09, 2010 9:54 am, edited 1 time in total.
-
Offline
- Posts: 876
- Joined: Tue Jul 24, 2007 8:54 am
FeyFre
Goodvin
Да я знаю, у меня Universal Viewer стоит, но привычнее запускать Акель. К тому же велики шансы, что может понадобиться отредактировать файл, поэтому временный read only режим во имя скорейшей доступности файла был бы очень кстати.Ну тут Вам в помощь lister32.exe (Просмотрщик от Total Commander-а отдельным приложением).
Воооот, это ключевой момент! Сам напарился с ним при допиливании XML парсера. Однако и эта проблема решаема: для юникода - простой проверкой на определенные условия, для мультибайтовых кодировок - на определённые lead bytes. К тому же как-то это ведь сделано в тех же просмотровщиках.Всплывет проблема разрезания на блоки: где бы это так разрезать файл, что-бы не разрезать пополам мультибайтный символ.
Goodvin
А ты не хочешь это дело загнать в БД? Поскольку найти повторяющуюся строку в 5 гиговом файле - это, извиняюсь, трындец.Искать в файле строки, как уникальные, так и многократно встречающиеся, делать автозамену определенной подстроки во всем файле и т.п.
-
Offline
- Posts: 15
- Joined: Wed Dec 08, 2010 9:47 am
Оно как раз из БД и выгружено.Fr0sT wrote:GoodvinА ты не хочешь это дело загнать в БД?Искать в файле строки, как уникальные, так и многократно встречающиеся, делать автозамену определенной подстроки во всем файле и т.п.
Эти 5 гигов - это XML-дамп большой базы данных.
Как раз в plain-тексте дампа поправить несколько строчек, а потом загрузить исправленное снова в БД значительно проще и нагляднее.
Это уже на практике выработалось за несколько лет.
Ну вот пресловутый EmEditor делает это, не напрягаясь.Fr0sT wrote: Поскольку найти повторяющуюся строку в 5 гиговом файле - это, извиняюсь, трындец.
Тратит считанные минуты.
И никакой не трындец.
Да и AkelPad в том куске файла, который показывает, тоже делает шустро.
Проблема лишь в том, как заставить AkelPad работать со всем файлом, а не с его десятой частью.
-
Offline
- Posts: 2247
- Joined: Tue Aug 07, 2007 2:03 pm
- Location: Vinnitsa, Ukraine
Goodvin
Я вижу два выхода:
1. Либо учим Акел(а заодно и плагины) работать со свопингом, что совсем не просто и займет уйму(уймище) времени.
2. Либо делаем Акел 64-битным(и перекладываем всю ответственность на кол-во памяти у пользователя), что немного быстрее, но я не уверен что мы имеем достаточно опыта миграции на 64, и выловим все подводные камни(что опять таки выльется в доп. время), да плагин тоже перевести нужно будет.
3. А разделить файлы на куски поменьше не пробовали? Я так понимаю качество обработки от этого не пострадает.
Я вижу два выхода:
1. Либо учим Акел(а заодно и плагины) работать со свопингом, что совсем не просто и займет уйму(уймище) времени.
2. Либо делаем Акел 64-битным(и перекладываем всю ответственность на кол-во памяти у пользователя), что немного быстрее, но я не уверен что мы имеем достаточно опыта миграции на 64, и выловим все подводные камни(что опять таки выльется в доп. время), да плагин тоже перевести нужно будет.
3. А разделить файлы на куски поменьше не пробовали? Я так понимаю качество обработки от этого не пострадает.