Вы не упомянули, был ли это ваш собственный сервер или вы использовали хостинговую компанию. Если вы пользуетесь услугами хостинговой компании, вам следует связаться с ними. Один сервер виртуального хостинга. Обычно у хостинговой компании есть несколько версий php на выбор. Обычно это делается с помощью директивы в файле .htaccess для домена.
Если вы используете vps или выделенный сервер, хостинговая компания должна быть в состоянии предоставить вам инструкции по обновлению версии php, или они могут даже обновить ее за вас.
Если у вас есть собственный сервер, быстрый поиск в Google предоставит ссылку на сайт Centos с инструкциями по обновлению. Однако, если вы используете что-то вроде cPanel, имейте в виду, что cPanel довольно разборчив в отношении установленных версий php и их местоположения. В этом случае нам понадобится дополнительная информация.
После некоторого дополнительного исследования выяснилось, что эта проблема меньше связана с ядром, а больше связана с взаимодействием rsync
и CIFS.
Насколько я понимаю, происходит следующее: когда rsync
закрывает целевой файл, CIFS (и, возможно, любая сетевая файловая система) гарантирует, что файл полностью очищен и записан на удаленный диск перед тем, как системный вызов close
возвращается. Это сделано для того, чтобы гарантировать любому приложению, что после успешного завершения операции закрытия файл был полностью сохранен, и нет риска каких-либо дальнейших ошибок, которые могут привести к потере данных.
Если этого не сделать, то приложение могло бы закрыть файл, выйти, думая, что операция сохранения прошла успешно, а затем (возможно, из-за проблем с сетью) данные все же не могли быть записаны, но к тому времени приложению уже слишком поздно что-либо делать с этим, например спрашивать пользователя, хотят ли они вместо этого сохранить файл в другом месте.
Это требование означает, что каждый раз, когда rsync
завершает копирование файла, весь дисковый буфер должен очищаться по сети, прежде чем rsync
сможет продолжить чтение следующего файла.
Обходной путь - смонтировать общий ресурс CIFS с параметром cache = none
, который отключает эту функцию и заставляет все операции ввода-вывода идти прямо на сервер. Это устраняет проблему и позволяет выполнять чтение и запись параллельно, однако недостатком этого решения является несколько более низкая производительность. В моем случае скорость передачи данных по сети упала со 110 МБ / с до 80 МБ / с.
Это может означать, что при копировании больших файлов производительность может быть лучше с чередованием чтения / записи. Для многих файлов меньшего размера отключение кеша приведет к меньшему количеству сбросов кеша при каждом закрытии файла, поэтому производительность может там повыситься.
Кажется, rsync
нуждается в опции, чтобы закрыть дескрипторы файлов в другом потоке, чтобы он мог начать чтение следующего файла, пока последний все еще очищается.
РЕДАКТИРОВАТЬ: Я подтвердил, что cache = none
определенно помогает при передаче большого количества небольших файлов (с 10 МБ / с до 80 МБ / с), но при передаче больших файлов (1 ГБ +) cache = none
снижает скорость передачи со 110 МБ / с до тех же 80 МБ / с. Это говорит о том, что медленная передача из многих небольших файлов связана не столько с поиском исходного диска, сколько с наличием большого количества сбросов кеша от всех небольших файлов.