Рекомендуемый метод для обновления PHP 5.1.6 до 5.2.x на CentOS 5.4

Я предположил бы Atom, ЦП обработает 100 Мбит трафика OpenVPN. При загрузке Вы могли бы найти, что Atom представит немного больше задержки, чем более быстрый ЦП, но это, вероятно, не будет значительно при рассмотрении против задержки любых длинных удаленных ссылок Вы имеете между сервером и клиентами.

Некоторые ненаучные результаты испытаний, рабочие данные между моим нетбуком с Atom ЦП к локальному серверу OpenVPN (более чем сеть на 1000 Мбит, но нетбук только имеет NIC на 100 Мбит):

dspillett@minirant:~$ time dd if=/dev/zero bs=1024 count=1048576 | nc -q 0 192.168.43.1 3333
1048576+0 records in
1048576+0 records out
1073741824 bytes (1.1 GB) copied, 91.2072 s, 11.8 MB/s
real        1m31.227s
user        0m1.792s
sys         0m25.874s
dspillett@minirant:~$ 

dspillett@minirant:~$ time dd if=/dev/zero bs=1024 count=1048576 | nc -q 0 192.168.44.1 3333
1048576+0 records in
1048576+0 records out
1073741824 bytes (1.1 GB) copied, 113.082 s, 9.5 MB/s
real        1m53.107s
user        0m1.468s
sys         0m15.337s
dspillett@minirant:~$

где 192.168.43.1 сервер, столь же замеченный только по локальной сети, и 192.168.44.1 та же машина, как замечено по ссылке OpenVPN по той сети. VPN находится в режиме моста, с помощью основанного на UDP соединения.

htop показал ЦП, облагаемый налогом больше во время теста VPN, чем количества user+sys от time укажите потому что time только рассчитывает ddактивность ЦП не VPN. Это показало cpu0 на уровне ~70% и cpu1 на уровне ~30% на всем протяжении теста, который предположит, что ЦП близко к пределу, который это может передать через OpenVPN в том тесте (что Atom был одноядерным, но с гиперпоточностью) - хотя этому все еще удалось переставить вперед в 9.5Mbyte/sec.

Как признак задержки, добавленной VPN (который будет комбинацией издержек от данных шифрования работы ЦП и наверху от метода туннелирования), проверяя с помощью ping-запросов с маленьким (значение по умолчанию, 56-байтовая полезная нагрузка) пакеты:

--- 192.168.43.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 8997ms
rtt min/avg/max/mdev = 0.138/0.166/0.183/0.015 ms
--- 192.168.44.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 8998ms
rtt min/avg/max/mdev = 0.544/0.614/0.860/0.091 ms

и больше (2 048-байтовая полезная нагрузка):

--- 192.168.43.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet los
rtt min/avg/max/mdev = 0.514/0.521/0.531/0.021 ms
--- 192.168.44.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9011ms
rtt min/avg/max/mdev = 0.710/0.997/1.437/0.173 ms

Очевидно, Вы получите различные результаты с VPN, обрабатывающей многочисленные связи, показывающие реальные модели трафика, таким образом, Вы могли бы хотеть выполнить некоторые более подробные тесты сами. Вы смогли отжимать больше с некоторой тонкой настройкой - мой набор OpenVPN в значительной степени работает на out-of-the значениях по умолчанию поля.

3

roundcube centos php linux

задан Stefan Lasiewski 30 July 2011 в 07:07

Ссылка

4 ответа

Я сказал бы, что любой из тех методов МОЖЕТ хорошо работать, но Вы не будете знать, пока Вы не попробуете его, таким образом, Вы лучше удостоверяетесь, что Ваши резервные копии в порядке. Однако обновление php намного легче на Linux, чем в Windows, и я был бы удивлен, были ли у Вас какие-либо проблемы. Принятие, которое Ваша установка, если не ванильный, по крайней мере, общая установка, необходимо согласиться с предварительно упакованным об/мин.

Возможно выполнить различные версии php на том же веб-сервере; к сожалению, можно только выполнить тот как модуль Apache, который оставляет Вас возящийся с интерфейсом CGI.

Красота современного об/мин состоит в том, что можно откатывать установку. Это сделает это немного легче.

С другой стороны, если Вы создаете из источника, можно просто создать его в другом каталоге. Затем все, что необходимо сделать, измениться, какая модификация php апачские загрузки, и изменяют местоположение файла php.ini, и Вы обновили без любого риска для Вашей текущей конфигурации.

0

ответ дан Satanicpuppy 3 December 2019 в 05:09

Ссылка

Я верю там многим решениям, и тот, который Вы выбираете, зависит от Вашего стиля системного администрирования.

'Легкий' путь состоит в том, чтобы установить php и связанные пакеты из другого репозитория, как этот. Позитивный аспект - то, что требуется меньше времени, оборотная сторона - то, что Вы доверяете внешнему источнику для своих двоичных файлов в Вашей системе, и для своевременных обновлений и для поддержания целостности и безопасности пакетов.

'Твердый' путь состоит в том, чтобы скомпилировать Ваше собственное. Я говорю, что это 'твердо', но это действительно не слишком плохо. То, что я делаю, у меня есть./команды настройки все сохраненные, поэтому когда новый выпуск произведен, я просто должен использовать те же переключатели для получения моей php среды то же, как это было для предшествующих выпусков.

Для систем без суетливых требований я использую бегство об/мин (на самом деле 5.1, хорошо работает для тех систем), но для тех, которые имеют пользовательские php среды, которые я все еще компилирую из источника.

Другое преимущество компиляции php самостоятельно - то, что Вы на самом деле понимаете и узнаете больше о программном обеспечении и как это работает над Вашим сервером. Можно гордиться этим, и это установит Вас кроме некоторых других системных администраторов!

0

ответ дан Dave Drager 3 December 2019 в 05:09

Ссылка

Просто установите Remi repo. И запустите:

yum update -y

и дождитесь завершения обновления, затем перезагрузите VPS с помощью init:

init 6

Теперь вы успешно обновили php в своей системе.

2

ответ дан 3 December 2019 в 05:09

Ссылка

Рекомендуемый метод для обновления PHP 5.1.6 до 5.2.x на CentOS 5.4

Теги

Похожие вопросы