Было у меня задание разработать парсер для сайта, что собственно мной было и сделано и сдано заказчику на тестирование. В процессе тестирования заказчик пожаловался, что уже в финале обработки платформа падает с ошибкой о «недостаточно памяти».
При разборе «полетов» я обнаружил, что ошибка сваливается при сохранении промежуточных данных в json формате, которые, в свою очередь, до сохранения в файл лежали в переменной типа «строка». Т.к. к финалу работы данных набиралось много, то происходило переполнение, казалось бы «бесконечной», строки. В итоге, чтобы определить, а сколько надо то памяти написал крохотную обработку, которая заполняла строку рандомным набором символов. Верхний предел я установил длинной примерно в 600 млн символов или, учитывая то, что строки в платформе 8.2 хранятся в utf-8, ~1.2 Гб памяти.
Результат — падение платформы на 350 млн символах.
Решение данной проблемы на просторах интернета есть, вот одно из них. Если ссылка битая, то вот, собственно, решение:
bcdedit /set increaseuserva 3000
таким образом, мы увеличили количество доступной памяти для процесса до 3 тыс Мб. Скорее всего поможет, не проверял.
Собственно код обработки
Процедура КнопкаВыполнитьНажатие(Кнопка)
генЧисел = Новый ГенераторСлучайныхЧисел(Секунда(ТекущаяДата()));
БольшоеСлово = "";
СчетчикСтрок = 0;
ВсегоСтрок = 0;
Для сч = 0 По 600 Цикл
СреднееСлово = "";
Для сч1 = 0 По 1024 Цикл
МалоеСлово = "";
Для сч2 = 0 По 1024 Цикл
МалоеСлово = МалоеСлово + Символ(генЧисел.СлучайноеЧисло(64,122));
КонецЦикла;
ВсегоСтрок = ВсегоСтрок + 1;
СчетчикСтрок = СчетчикСтрок + 1;
ОбработкаПрерыванияПользователя();
СреднееСлово = СреднееСлово + МалоеСлово + Символы.ПС;
Если СчетчикСтрок >= 50 Тогда
Состояние("Прошли - " + Строка(ВсегоСтрок));
НадписьПройдено = "Прошли - " + Строка(ВсегоСтрок);
СчетчикСтрок = 0;
КонецЕсли;
КонецЦикла;
БольшоеСлово = БольшоеСлово + СреднееСлово;
КонецЦикла;
КонецПроцедуры
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
На две недельки бы раньше… Мне из-за этой ошибки пришлось с ХР на 8 перейти ) (времени разбираться небыло)
Но всё равно, спасибо, буду знать 🙂
(1) greenLiss, автор статьи не сказал этого, но bcdedit какбэ намекает, что способ в статье на xp работать не будет.
(2) cool.vlad4, ну значит, не зря перешел 🙂
А для Windows Xp нужно в boot.ini дописать параметр /3Gb:
например
multi(0)disk(0)rdisk(0)partition(1)WINDOWS=»Microsoft Windows XP Professional RU» /noexecute=optin /fastdetect /3Gb
Я просто в boot.ini прописал ключ /3GB.(4) Опоздал)))Можно добавить еще что-нибудь, но для ХР, имхо, это максимум что можно сделать, несмотря на неплохое железо.
на 7-ке 32 битной аналогично было при обновлении даже, на 64-битной нет ошибки! хотя памяти одинаково было озу
Чего я не указал в статье, так это конфиг железа и ОСи.
Тестирование проводилось на Win 7 Pro x64 Core i5-4670/ 16Gb оперативы. Версия 1С использовалась 8.2.18.104 обычные формы. Клиент тестил на Win XP Pro 3Gb оперативы. Для него критичен запуск на XP.
А сколько в среднем по времени тест будет длиться при запуске с обычного пользовательского компа, например, core i3 4-8 ГБ ОЗУ ?
(8) xten, у меня тест продлился примерно 30 минут, точно не засекал. Пообедал, чуть поработал, открыл — ошибка )) от ядрённости процессора не зависит, 1Ска однопоточна, зависит от частоты процессора. Мне кажется у вас будет так же, как и у меня, может чуть медленней. Я попытался и так оптимизировать рост строки по блокам, т.к. платформа в этом отношении достаточно тупая, в одном цикле при добавлении буквы за буквой примерно уже на 5Мб текста начинаются жуткие тормоза при сложении строк. Оптимально генерить блоки по мегабайту и добавлять к основной строке, собственно также и стоит организовывать чтение больших текстовых файлов, последовательно блоками.
Интересно, относится ли такое ограничение к строкам, получаемым как результат штатных функций 1С? Например, вы упоминаете парсинг сайта. ЭлементыФормы.ПолеХТМЛ.ПолучитьТекст() — как себя поведёт на таких объёмах, сыпанётся?
(10) Yashazz, Если теоретически предположить что страницы объемом более 600 Мб бывают (как в моем синтетическом случае), то, я думаю, однозначно будет падение системы. Только перед этим она будет дооолго думать))
(9) Nicolas_d, была статейка про особенности конкатенации строк в 1С — смысл в том, что начиная с определенного размера «бесконечная» строка перестает хранится в памяти, и переносится во временный файл на жесткий диск, что существенно замедляет работу с ней.
Панацея — клиент 1С 64-разрядный под Linux 🙂
(9) Nicolas_d,
Откуда такие сведения?
(14) Andreynikus, прям в мануал не тыкну, не видел такого, говорю о том,что вижу при загрузке процессора именно клиентом 1С:Предприятия. Явно видно, что любая обработка выполняется последовательно в один поток плюс «фризы» самой конфигурации при выполнении явно об этом говорят. Про сервер не говорю и не имею его ввиду. К сожалению, многопоточных вычислений в одной обработке выполнить пока невозможно.
(14) Andreynikus, ну очевидно, что 1С многопоточна. хотя бы потому, что это gui-евое приложение. вероятно он имел ввиду, что из 1С кода без ВК, нет возможности управлять более чем одним потоком.
(16) вот Вам немного информации к размышлению. Имею УПП, объем базы 350 Гб, сервер, 120 Гб оперативы. При обновлении (то есть, просто сравнить конфигурации основную и новую поставщика) с помощью компа 4 Гб оперативны , core 2duo требуется время 30 минут. На компе 24 Гб оперативны, i7, требуется 3 минуты. При переносе темповских файлов 1С в ram-диск, то есть чтобы файлы сравнения конфигурации помещались не на физический диск , а в оперативную память или работе на SSD-диске, выигрыш по времени составил около 10%. Во всех процессах, контролировал загрузку железа в штатном мониторе ресурсов. Не знаю о какой многопоточности тут говорят, но как 1ядро напрягалось, так и напрягается сейчас. Никакие апгрейды железа для 1с, кроме как процессора, ощутимого выигрыша не дают! Не думаю, что об это сама 1с напишет, это все равно, что признаться в своей ущербности!
(17) DoctorRoza, поддерживаю
(17) DoctorRoza, если признаетесь, что не знаете, что такое поток и многопоточность, тогда советую почитать чего-нибудь на эту тему. как вы собрались определять многопоточность по загрузке процессора — загадка, множество потоков работает в пределах одного процесса, и многопоточность запросто существует на одноядерных процессорах, (а иначе как на таких компьютерах работают другие программы?) короче советую вам обновить свои знания, ущербность 1С здесь ни при чем. забавно, что не зная такой простой вещи (это азы программирования), вы мне даете инфу для размышления )))
Хех, наверное завершу холивар про многопоточность 1С. Давайте расставим все точки над Ё. Сама платформа (в нашем случае клиент 1С, неважно какой тонкий или толстый) многопоточна, в этом сомнений нет. Достаточно заглянуть в монитор ресурсов:
Нет никаких сомнений, что через энное место запустить даже отдельные потоки для обработки данных (вспоминаем фоновые процессы), все работает очень даже ничего.
Но остается непреложным факт того, о чем я и говорю изначально, штатными средствами в одной внешней обработке или отчете никак нельзя запустить выполнение нескольких задач параллельно. Кто то может сказать, а как же обработчик ожидания? Он запускается в том же потоке обработки и ожидает своей очереди на выполнение, даже если его время подошло, проверено. Думаю этот вопрос можно закрыть.
(20) Nicolas_d, а я в (16) писал что-то иное? я и писал, что 1С платформа многопоточна, это настолько очевидно, что даже никакие мониторы ресурсы мне не надо запускать. но тем не менее вы поддержали doctorraza, который мне возразил. я слабо представляю, как можно написать гуевый(это не ругательство) клиент-сервер, используя один поток.
(17) DoctorRoza, и вот вам инфа для размышления. при увеличении числа используемых потоков, программа наоборот может тормозить. это я к тому, чтобы вы не думали, что есть какая-то линейная зависимость число потоков — работа программы.
(21) cool.vlad4, все верно поддержал, но только в том, о чем написал выше
(23) Nicolas_d, ну и о чем? я разве писал, что «штатными средствами в одной внешней обработке или отчете» можно «запустить выполнение нескольких задач параллельно»? я как раз и написал «что из 1С кода без ВК, нет возможности управлять более чем одним потоком.» Ну и о чем спор?
Наконец-то внятный ответ на совершенно идиотское сообщение программы. Огромное спасибо за разъяснение технической подоплёки.
порадовала публикация и комментарии к ней 🙂
(17) DoctorRoza,
Не о чем спорить. Распараллелить 1С по потокам можно либо через ВК, либо через фоновое задание (без разницы как запущенное). Но это всё запуск в явном виде.
А всё остальное выполняется строго в одном потоке независимо от того, сколько потоков показывает монитор ресурсов (например, могу точно утверждать, что 1 поток выделяется на обновление отображения, не меньше 2-х на физическое чтение/запись БД и т.д. — отсюда и большое количество потоков в мониторе ресурсов).
Не верите? Запустите диспетчер задач (обязательно на многоядерном/многопоточном компе, иначе просто ничего не увидите), запустите какую-нибудь навороченную сильно ресурсоёмкую и долго выполняющуюся задачу в 1С и посмотрите, какая будет нагрузка на ядра процессора.
(27) FractonKireyev,
Это и есть многопоточность приложения 🙂 Вы чего хотели, чтобы у вас чтение файла в несколько потоков выполнялось? Или операцию умножения или запрос к БД несколько потоков обрабатывали?
Насколько я понял, основная суть недовольства тут не столько в многопоточности платформы 1С, сколько в неумении платформы распределить свои потоки по разным процессорам.
(28) insurgut,
Вы вообще не поняли сути моего поста. Это просто объяснение происхождения множества потоков ядра при одном сильно нагруженном потоке.
Читайте внимательно мой текст (27) — там я пишу о том, как распараллелить вычисление.
(29) FractonKireyev, то, что синтаксис 1С не позволяет создавать и управлять потоками программисту — это понятно. С этим никто не спорит. Я же уточнил, что по сути говоря «однопоточная» люди подразумевают неспособность платформы 1С распределения своих порожденных потоков работать на нескольких физических/логических ядрах процессора.
P.S.
уточню, что при одном сильно нагруженном
потокепроцессе. 1 процесс — множество потоков. У одного потока — нет подмножества потоков 🙂 Будем называть вещи своими именами.(0) Автор, напишите, пожалуйста, большими буквами, что данная рекомендация относится только к 32-разрядным ОС.
Данная рекомендация была актуальна лет 10 назад но никак не сейчас. комментарии повеселили …
(32)
Обоснуйте.
(17) DoctorRoza,
Да, совершенно верно…Прирост даст ещё разгон тактовой частоты процессора,а ядер ставь хоть сто, 1С не ускорить:))))))) :((((((((((
И 8.3 точно такая же, ядронезависимая
У меня такое сообщение бывало, в основном, из — за кривых бухгалтерских ручек — достаточно создать документ от, скажем, 13 года(0013 года, вернее:-)))))))))))))), и, при пересчёте итогов какого — нибудь регистра, в который сделал движение этот документ, за 2000 лет, можно увидеть это весёлое оконце:-)))))))))0
А кто-то знает почему движок 1С ядронезависимый. Почему он всегда работает с 1С ядром. Кстати, такая же фигня была и в WOT (World of tanks), она задействовала всегда одно ядро. Однако после большого количества упреков и наездов они подняли задействованность до 2 ядер. Где стоит ограничение на количество ядер? Явно не в СУБД не в .Net на котором написан виндовый клиент (поправьте, если ошибаюсь). Тогда в чем?
(36) haggart, виндовый клиент писан не на .Net, чистые плюсы (С++). Ограничений на ядра нет, просто они не используются, лень компании делать полные реинжинириг и перестройку архитектуры существующего решения/платформы (может это будет в 9й версии платформы?). 8я платформа начинала развитие, когда многоядерность была в диковинку и никто не помышлял распараллеливать нагрузку программы на физические ядра. Компания нацелена на извлечение прибыли и пишут просто большой неоптимизированный код, как известно, железо нынче дешевле труда программистов. На многие просьбы писателей от конфигуратора 1С не дает ответов и решения. Конфигуратор в чистом виде просто убожище. Спасибо, что есть такие люди, как Орефков c его «снегопатом», который замечательно продолжает телепата из 7й платформы + плюшки опенконфа. Шота меня понесло ))
(37) Nicolas_d,
Спасибо, что разъяснили ситуацию. В 1С 7.7 действительно пользовался орефковскими примочками (телепат). Даже не знал, что он и для 8.2 разработал нечто подобное. Вы пользовались, удобная утилита (или как «снегопат» назвать)? Просто релизы у 1С 8.2 меняются достаточно часто, а я так смотрю, что для каждого релиза свой «снегопат» и последний для 8.2.16.
(38) haggart, по поводу снегопата, являюсь пользователем демо версии, она остановилась на 8.2.18.104. Меня пока устраивает. Обновил компоненту SciColorer, чтобы не было выпадений при отладке и все работает очень неплохо. Рабочие релизы стоят денег, покупать пока не готов, потому как есть надежда, что с 1С завяжу в пользу нормального программирования под вэб и сервисы, да мобильные приложения. Пока приходится работать «многостаночником» и 1С всех платформ и конфигураций, web разработка, разработка настольных приложениях
1С не поддерживает разделение исполнения на независимые потоки. Но получится ли обойти это дело искусственно?Например, есть массив данных для обработки. Делим его на части и для каждой стартуем своё фоновое задание. Отдельный вопрос как синхронизировать результаты выполнения (писать в регистр или ТЗ в хранилище, например).
(40) Osiris_, искусственно получается, я упоминал это в коментариях, т.е. фоновые задания выполняются в отдельном потоке, вроде даже каждое задание. Но, нагрузка так и идет на одно физическое ядро. Поэтому на рабочих серверах 1С рекомендуется выключать hyper threading, чтобы не делить физическое ядро на 2 виртуальных, дает некоторый прирост в скорости работы
(32) sanek_gk, вы либо неопытный разработчик, либо не разработчик. С каждым новым релизом вопрос оптимизации становится всё острее. Сейчас, например, на 8.3.408 опять регулярные падения платформы с этой ошибкой при обновлении больших конфигураций, таких как УТ 11.1 и более тяжелых. Решения такого типа, как увеличить размер допустимого использоваия ОЗУ процессом (bcdedit) уже не помогают. Решения пока нет
далеко не все вычисления можно распараллелить, пользователи работаю в разных потоках, от друг друга зависят только в пересекающихся блокировках в принципе… по поводу работы инструментов ТИИ и обновления конфигурации, они как были написаны в 2005 году, так и не развивались… поэтому они не рассчитаны на большие объемы в принципе, в собственно посмотрите как ТИИ делается на уровне запросов, там простой перебор записей, даже не выборка по Н-позиций
Бывали в недалеком прошлом такие ошибки на моем ПК, даже конфигуратор 8.2/8.3 падал при обновлениях. Винда 7 х86 2 Гига ОЗУ.
Решение было по сути сразу найдено 4 гига памяти вместо двух, но вот незадача, на моем ПК все так же невозможно было произвести расчет проводок в ЗУП 2.5 для БП 2.0/3.0.
Ну что, переставил еще и винду на 7 х64.
Полет нормальный.
Вообще пытался понять, когда падает прога от нехватки памяти и что страранно, даже при свободном гиге памяти валилась с ошибкой. Видимо, если прога хочет сожрать N метров памяти и ее нет, то она заранее вываливается с ошибкой, хотя уверен, что ну не нужен был ей гиг памяти, управилась бы и в том что было!, но…