Какой Linux на 64 бита может сделать, тот Linux на 32 бита не может?

В любой совместимой POSIX оболочке (bash, dash, ksh, и т.д.):

for file in sw.ras.[[:digit:]][[:digit:]][[:digit:]]; do
    mv "${file}" "${file/ras\./}"
done

Или с rename:

rename 's/ras\.//' sw.ras.[[:digit:]][[:digit:]][[:digit:]]
5
10.06.2014, 16:06
2 ответа

32-разрядные x86 центральные процессоры (начиная с Pentuim Pro) поддерживают до 64 гибибайт RAM (использующий PAE). (Опция ядра "CONFIG_HIGHMEM64G" должна быть установлена на самом деле использовать его). Каждое приложение может только видеть 4 гибибайта за один раз (и некоторые из тех 4 ГиБ должны использоваться для других вещей, точной суммы в зависимости от "Установки ядра" разделения памяти),

64-разрядные операционные системы имеют некоторые другие преимущества также, такие как доступ к дополнительным регистрам на ЦП, который может ускорить некоторые типы приложений (позволив более временным данным быть сохраненным в намного более быстрых регистрах, а не основной RAM)

11
27.01.2020, 20:32
  • 1
    Предел на 4 гибибайта особенно становится проблемой для MySQL, MongoDB и вероятно других. –  Mark McKinstry 03.01.2013, 07:38
  • 2
    Если Вы заказали 32G поршень, нет действительно никакой причины использовать ОС на 32 бита. ОС на 64 бита должна быть значением по умолчанию без клиентского выяснения. –  John Siu 03.01.2013, 07:43
  • 3
    Добавляя к комментарию John Siu, я подверг бы сомнению любой хост, который установит сервер с 32-разрядной ОС, зная, что это получало 32 ГБ RAM. Настольная система даже была бы сомнительна, но определенно не с сервером. –  Daemon of Chaos 03.01.2013, 15:56
  • 4
    Предел на 4 ГБ для приложений на 32 бита на ядре на 64 бита, на ядре на 32 бита предел составляет 3 ГБ. –  ctrl-alt-delor 10.06.2014, 15:59
  • 5
    видит также x32 — en.wikipedia.org/wiki/X32_ABI –  ctrl-alt-delor 27.06.2014, 13:47

Весь Ваш поршень доступен даже с ядром на 32 бита. Основное различие, вероятно, что любое приложение не может обратиться больше чем к 3 ГБ памяти. Я не знаю, используете ли Вы действительно такие приложения (обычно базы данных или графические приложения), иначе можно проигнорировать проблему. Обратите внимание на то, что приложения на 64 бита требуют большей памяти (потому что регистры и адреса больше), и загрузитесь медленнее от диска (потому что двоичные файлы больше).

Так, прежде, чем оставить пространство пользователя на 32 бита, лучше проверьте свои требования. Кроме того, многие дистрибутив Linux обеспечивают ядра на 64 бита, которые будут использоваться с пространством пользователя на 32 бита: если Вы обращаетесь к ПК, то проверьте, как Debian обеспечивают amd64 ряд ядра для i386 (32 бита) архитектура также.

6
27.01.2020, 20:32
  • 1
    что относительно php и апача? Существуют тонны процесса, и они могут рассчитать как одна программа. –  user4951 04.01.2013, 02:57
  • 2
    @JimThio, Вы могли лучше объяснить, каково Ваше беспокойство? php и апач обычно не требуют большой памяти вообще. тоннами процессов отлично управляют ядра Linux на 32 бита. Я думаю, что даже ядро на 64 бита не имеет большего PIDs, так вероятно, они не могут выполнить больше процессов одновременно. Если Вы обращаетесь к общей памяти среди различных апачских потоков, это не проблема, обычно, так как это - путь ниже, чем память, данная базам данных. –  eppesuig 04.01.2013, 10:53
  • 3
    Это - процесс, который имеет предел на 3 ГБ. Приложение не является понятием операционной системы. Если приложение имеет 100 процессов затем, общая память составляет меньше чем 100 × 3 ГБ. Я говорю, что меньше, чем, потому что они, вероятно, совместно используют некоторых: общие библиотеки, и возможно там кодируют. –  ctrl-alt-delor 10.06.2014, 16:03

Теги

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