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

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

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

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

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

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

Поэтому я предлагаю вам смириться с этим гневом и разочарованием и решить, как помочь себе.

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

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

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

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

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

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

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