Внутренняя ошибка сервера загрузки файла

Question

Ошибка
У меня есть веб-приложение, с помощью массового пользователя (Plupload) для фото и когда я загружаю сказать двадцать фотографий, примерно шесть (около 30%) потерпит неудачу с внутренней ошибке сервера , Я проверил Apache error.log для этого домена, и у него нет ничего нового (я знаю, что смотрю на правильный error.log, поскольку здесь показывают более старые ошибки).

Это происходит только на моих серверах VPS на Dreamhost (моем хостинг-провайдере), а на моем сервере разработки он работает шелковисто.

О, и вещи использовали, чтобы нормально работать месяц назад, а затем просто начали сбой. Тогда я использовал Uploadify, и с тех пор, как использовал Flash, мне не удавалось отлаживать ошибки загрузки.

файлы и скрипт
Загруженные файлы фотографий, всего около 100 кБ большой, несмотря на то, что я успешно загрузил (и все еще) 3 MB фото. Мой .htaccess, естественно, не изменяется во время загрузки. На стороне сервера есть скрипт PHP, который использует библиотеку GD2 для перемещения и изменения размера фотографии.

состояние сервера
Я недавно модернизировал свой VPS от 300 до 400 Мб оперативной памяти. Эта вещь работала, и я обновил ее только для того, чтобы память была исключена из-за причины. Также мой предел памяти для PHP составляет 200 МБ, поэтому это должно быть достаточно.

Я получаю могучую разочарование, что Dreamhost не хочет, чтобы помочь, заявив, что «мы не можем нести ответственность за ошибки код вызывает» и «Мы все еще не будем в состоянии помочь вам в отладке проблемы, к сожалению, «.
Это была неделя редкой «поддержки», в то время как мое приложение не работает, и мои клиенты разочарованы.

Вопросы

1. Является ли это своего рода «Вы самостоятельно» поддерживают стандарт через промышленности, т.е. бы ваш хост справиться с этим по-разному?
2. Как именно может Я отлаживаю это?

Answer 1

Я собираюсь предположить, что у вас стандартная настройка Apache + PHP. Одной из возможных настроек является предварительная конфигурация; в этом случае Apache будет адаптироваться к загрузке системы, разыграв больше детей.

Имея всего 400 МБ ОЗУ, вы довольно плотно, поэтому, если вы используете 20 процессов, каждый из которых занимает 200 МБ (при условии, что каждый процесс обрабатывает довольно большие файлы с использованием GD), вы попадаете в горячие воды с памятью менеджер.

Я бы уменьшил общее количество экземпляров до 2, чтобы увидеть, как это будет происходить; также следите за использованием памяти, запустив top.

Независимо от того, что вам может быть полезно запустить отдельный диспетчер задач, такой как Gearman, для выполнения задач изменения размера, чтобы загрузка была направлена ​​только на перемещение загруженного файла и запуск задачи изменения размера; таким образом, вы можете значительно сократить объем памяти, необходимый для запуска ваших экземпляров PHP.

Answer 2

пытается ответить на вопрос 2: если вы проверили весь свой код, и вы не обнаружили никакой ошибки, я считаю, что самое лучшее, что вы можете сделать, это проверить версию всех программ, запущенных на сервер (apache, php, ...), например, я помню, что у меня была проблема с веб-службой, на которой он работал на apache и php, версия php была 5.2.8, и после большого расследования я обнаружил, что в этой версии возникла проблема с анализом данных xml.

Answer 3

Что касается вашего Q1: простой ответ заключается в том, что вы получаете то, за что платите. ОЗУ 300Mb Dreamhost VPS стоит ~ $ 360 в год. Для этого вы получаете услугу VPS и ответы на отказ службы, связанный с предоставлением виртуальной среды. ОС, стек программного обеспечения и приложения находятся за пределами этой области обслуживания. Зачем? Такой вид поддержки базы знаний может стоить 50-300 долларов США в час. Вы неразумны и обманываете себя, если вы ожидаете, что Dreamhost предоставит такие услуги pro-bono. Вот такие сайты, как этот.

Итак, мое предложение состоит в том, что вы всасываете этот гнев и расстройство и решаете, как помочь себе.

Что касается вашего Q2. (i) Вам нужно понять, куда идут ваши ошибки Apache; (ii) Точно любые ошибки SQL, если вы используете D/B. (iii) Вы должны убедиться, что регистрация ошибок PHP включена и проверить, где будут вести журналы PHP. (iv) Вам необходимо проверить эти журналы и убедиться, что ведение журнала работает правильно, используя небольшой скрипт, который генерирует ошибки времени выполнения.

Вы также должны рассмотреть возможность использования расширенных средств, таких как php_xdebug, для повышения уровня ведения журнала и внедрения регистрации приложений.

В моем опыте системы и функции редко умирают молча. Однако программисты приложений часто игнорируют статусы возврата и т. Д. Например, в библиотеке GD imagecopyresized() может выйти из строя, и он возвращает код состояния, чтобы сообщить приложение, когда он есть, но если приложение не проверяет этот статус и действуйте соответствующим образом, тогда это может закончиться тем, что они бесшумно выходят из строя, и просто появляются пользователю (или разработчику) как «он просто перестает работать».

Мой последний комментарий: вы должны действительно рассмотреть возможность настройки частного VPS в вашей среде разработки, которая отражает конфигурацию вашей продукции Dreamhost, и использовать ее для интеграции, приемочного испытания и поддержки. Это довольно легко сделать, и вы можете испортить это и добавить опции отладки/что если, а затем откат, не загрязняя окружающую среду. Такие инструменты, как VMare Appliances и VirtualBox, упрощают работу. См. this blog post для описания того, как я это сделал для своего размещенного сервиса.

Answer 4

Что касается первой части вопроса: Dreamhost предлагает платную службу поддержки с «обратным вызовом». Мы использовали это один раз, чтобы немного опуститься. Они очень хороши при общей поддержке (лучше, чем многие хосты IMO), но вы не можете рассчитывать на выделенный сервис, и они должны решать множество вопросов. Но платите за обратный звонок, и примерно через 2 минуты на телефоне вы можете получить ответ, который хотите, плюс они получат свои 10 долларов США (повторяющиеся) на время. Вы оба побеждаете. Не забудьте отменить повторяющиеся обвинения.

Что касается второй части вопроса, у нас была такая же проблема с ними. Их ответ (как было предложено Линусом в комментариях) заключался в том, что они поддерживают подсчет использования процессором всех процессов, используемых вашим «пользователем». Если эта сумма превышает пороговое значение, они просто убьют процесс (ы), чтобы уменьшить циклы. Нет сообщений об ошибках, никаких предупреждений, нет ничто. Процессы могут включать MySQL, CGI (perl) или PHP. Невозможно контролировать или прогнозировать, и мы не могли запрограммировать его. Решение ... не DreamHost, к сожалению. (webhostingtalk.com предоставит вам массу идей для хоста).Поэтому мы используем некоторые сайты, но не для других.