Как выполняются теги CFX в Coldfusion 8?

Question

В моей компании мы столкнулись с некоторыми проблемами памяти в последнее время. Одна вещь, которую мы сделали, - увеличить размер кучи в JRUN, но теперь мы замечаем некоторые побочные эффекты.

Один из них - это тег CFX, который обрабатывает изображения. Когда мы его используем, он не может загружать файлы, которые мы иногда приводим. Наша нынешняя идея заключается в том, что для обработки изображений все изображение должно загружаться в память. Похоже, что это приводит к ошибкам в больших файлах, на которые потребуется 200 МБ памяти для хранения всего.

Что я хочу знать, так это то, как Coldfusion обрабатывает загрузку и выполнение тегов CFX. Поскольку тэг CFX, в частности, был написан на C++, я бы подумал, что он не обязательно будет использовать кучу Coldfusion (поскольку она хранит только данные Java), и мы не видим кучевых всплесков, когда мы что-то обрабатываем.

Я предполагаю, что главный вопрос заключается в том, как выполняется CFX: выполняется ли он как поток под JRUN или создается собственный процесс Windows, который работает в своем собственном пространстве пользователя? И, если он работает под JRUN, какое пространство памяти это использует при выполнении, и есть ли способ контролировать его?

Answer 1

CFX определенно работает как поток под JRUN, и данные распределяются с Java на C++ через уровень JNI. Так что да, он загрузит все изображение в кучу, используя файл по умолчанию для открытия/чтения (под обложками), а затем передаст двоичный код вашему тегу C++. Обращение с большими файлами изображений (или большими файлами в целом) всегда было проблемой с CF на мой взгляд. Существуют некоторые «чистые Java» решения для обработки изображений, которые обеспечат лучшую производительность, или вы можете использовать что-то вроде «imagemagik», которое передает имя файла и путь к оболочке, а -, выполненный отдельно. Это мое занятие.

Answer 2

Я думаю, что если вы используете 32-битный процесс, он может получить доступ только к 2gig. Если куча равна 1gig, тогда память без кучи будет 60-200 + meg, а затем добавьте в память для каждого потока, который выполняется процессом (и количество потоков становится еще выше, когда вы кластеризованы), тогда иногда бывает «нет», t, что много места памяти осталось в вашем процессе. Кроме того, как я понимаю, различные библиотеки DLL отображаются в вашем пространстве памяти где-то в верхней части диапазона памяти, что означает, что когда тэг обработки изображения пытается выделить очень большой блок смежной памяти (вне кучи - это моя догадка) , для него нет единого блока. Этот ответ несколько умозрительный, поэтому не воспринимайте его как Евангелие, но, возможно, стоит посмотреть на программы, которые могут визуализировать карту памяти процессов.