Эта проблема, похоже, напрямую связана с печально известным лимитом 2 ГБ, и я не уверен в этом, если его проблема с 32-битным PHP. Я видел комментарии, связанные с HTTP, которые не предназначены для таких больших файлов. Тем не менее, я предпочел бы исчерпать это направление, прежде чем принимать решение о каких-либо фундаментальных изменениях в отношении того, что было доказано в настоящее время. Как следует из названия, мне нужно загрузить> 2 ГБ файлов, самый большой на сегодняшний день 3,8 ГБ. У меня есть форма, построенная с использованием jQuery-file-upload, у которой не было проблем с отправкой каких-либо файлов (все меньше <2 ГБ) до тех пор, пока не начнутся эти большие. 3,8 ГБ занимает около 5 минут для загрузки из файла-загрузки, а индикатор выполнения достигает 100%. Однако сообщенная ошибка после загрузки является типом 1, который предполагает, что предел размера файла был нарушен.
Если я отслеживаю использование диска на сервере во время загрузки, он будет иметь следующие свойства образца: перед загрузкой диска используется 30%, поскольку загрузка продолжается, это увеличение увеличивается, 31%, 32% …. 45%, 46% и т.п. Однако примерно в 2 Гбайт точки использования диска снижаются до 30%, тогда как загрузка файлов клиент / браузер продолжается. Когда использование дискового пространства серверов перестает увеличиваться, клиент может получить только 60% загрузки. Тем не менее клиент по-прежнему остается на 100%, но не принимается сервером, так как состояние диска никогда не отключается на 30%.
Я запускаю 64Bit Ubuntu (последний) с Apache / 2.2.22 (Ubuntu) и PHP версии 5.3.10-1ubuntu3.2. После многих дней поиска и поиска по поиску решения я все равно не могу загрузить файл 3.8GB после изменения так много настроек. Я приведу список изменений ниже, но на этом этапе я думаю, что это может быть 32-битная проблема с PHP, поэтому, если кто-нибудь может предложить ссылку, стоящую за мной или ее решение, я бы это оценил.
В Apache2 я установил следующее:
- apache2.conf I've set Timeout to 900 - httpd.conf I've set LimitRequestBody to 0 - .htaccess in the file upload directory I've set: - LimitRequestBody to 4939212390 - php_value upload_max_filesize 4831838208 - php_value post_max_size 4939212390 В php.ini я установил следующее:
- UPLOAD_MAX_FILESIZE 4831838208 - POST_MAX_SIZE 4939212390 - max_execution_time 120 - max_input_time 60 - memory_limit 128M
Если я запустил на сервере следующее: кажется, что у PHP нет 32-разрядной проблемы, но я не уверен на этом этапе.
php -r "echo PHP_INT_MAX;" 9223372036854775807
Как я уже говорил, любые идеи будут высоко оценены.
ОБНОВИТЬ:
Решили эту проблему, поэтому благодаря @BogdanBurim за то, что предложили подход к основам:
Мне удалось загрузить файл размером 3,8 ГБ по HTTP со следующими настройками:
В Apache2 я установил следующее:
- apache2.conf I've set Timeout to 900 - httpd.conf I've set LimitRequestBody to 0 - .htaccess in the file upload directory I've set: - LimitRequestBody to 0 - php_value upload_max_filesize 0 - php_value post_max_size 4939212390 - .htaccess in the php temp directory (in my case its /tmp/) I've set: - LimitRequestBody to 0 - php_value upload_max_filesize 0 - php_value post_max_size 4939212390
В php.ini я установил следующее:
- UPLOAD_MAX_FILESIZE 0 - POST_MAX_SIZE 4939212390 - max_execution_time 120 - max_input_time 60 - memory_limit 128M
Единственной важной частью этого решения было удаление MAX_FILE_SIZE, HTML из формы загрузки:
<input type="hidden" name="MAX_FILE_SIZE" value="4939212390" />
Наличие этого набора постоянно вызывало ошибку типа PHP 2, поэтому php не смог обработать установленное более 32-битное целое число. Удаление этого вызвало ошибки PHP типа 1, пока я не изменил UPLOAD_MAX_FILESIZE на 0 всюду, и hey presto теперь работает !!!!
http://php.net/manual/en/features.file-upload.errors.php
Решили эту проблему, поэтому благодаря @BogdanBurim за то, что предложили подход к основам:
Мне удалось загрузить файл размером 3,8 ГБ по HTTP со следующими настройками:
В Apache2 я установил следующее:
- apache2.conf I've set Timeout to 900 - httpd.conf I've set LimitRequestBody to 0 - .htaccess in the file upload directory I've set: - LimitRequestBody to 0 - php_value upload_max_filesize 0 - php_value post_max_size 4939212390 - .htaccess in the php temp directory (in my case its /tmp/) I've set: - LimitRequestBody to 0 - php_value upload_max_filesize 0 - php_value post_max_size 4939212390
В php.ini я установил следующее:
- UPLOAD_MAX_FILESIZE 0 - POST_MAX_SIZE 4939212390 - max_execution_time 120 - max_input_time 60 - memory_limit 128M
Единственной важной частью этого решения было удаление MAX_FILE_SIZE, HTML из формы загрузки:
<input type="hidden" name="MAX_FILE_SIZE" value="4939212390" />
Наличие этого набора постоянно вызывало ошибку типа PHP 2, поэтому php не смог обработать установленное более 32-битное целое число. Удаление этого вызвало ошибки PHP типа 1, пока я не изменил UPLOAD_MAX_FILESIZE на 0 всюду, и hey presto теперь работает !!!!
Если у вас есть доступ к конфигурации apache virtualhost, вы также можете изменить эти параметры для определенного URL-адреса загрузки (вы также можете добавить это в свой файл .htaccess):
С помощью этого кода:
<LocationMatch "/index.php/url-of-your-upload.php"> php_value max_execution_time 0 php_value upload_max_filesize 0 php_value post_max_size 4939212390 php_value memory_limit 4G LimitRequestBody 0 </LocationMatch>
Директивы LocationMatch позволяют вам выбрать URL-адрес (вы можете использовать reg exp)
Вопрос в том, почему вы используете свой браузер для загрузки> 1 ГБ. Подумайте о том, что самые распространенные службы обмена файлами имеют максимальный размер загрузки файлов до 1 ГБ через браузер. Что произойдет, если пользователь-загрузка завершится неудачей, вам придется перезапустить весь процесс.
Вы заглянули в альтернативы, если у вас есть такие большие загрузки файлов, торренты, ftp или личный клиент для загрузки, такие как rapidshare, fileupload, megaupload и т. Д. Есть.
Вы ограничены из-за ограничения размера файла, установленного на POST. Если вы решите использовать HTTP для загрузки больших файлов, которые я бы обескураживал, оптимальным решением было бы разделение файла и загрузка меньших разделенных частей, а затем повторная сборка файла.