Ưu điểm của việc nâng cấp Windows Server 32 bit và SQL Server lên 64 bit?


13

Giả sử rằng tôi có hộp Windows Server 32 bit vận hành một số ứng dụng máy chủ cùng với SQL Server, với mức sử dụng RAM khoảng 2 GB vào thời gian cao điểm.

Những lợi thế của việc nâng cấp HĐH Windows Server và SQL Server lên các phiên bản 64 bit tương ứng, với các ứng dụng máy chủ còn lại là 32 bit? Các phiên bản 64 bit cho phép truy cập hơn 4 GB RAM, nhưng vì 4 GB không được sử dụng đầy đủ, điều đó có thể khiến bản nâng cấp không?

Phiên bản: Windows Server 2008 R2, SQL Server 2008 R2 Phiên bản trung tâm dữ liệu

Cảm ơn

Câu trả lời:


19

Liên quan chặt chẽ: Lý do chính đáng để giữ HĐH máy tính để bàn Microsoft Windows 32 bit

Bạn đang sử dụng HĐH 64 bit. Server 2008 R2 là máy đầu tiên chỉ hỗ trợ CPU 64 bit.

Các phiên bản "mới hơn" của Windows thậm chí không được thiết kế cho 32 bit. Bạn có thể sẽ không tận dụng bất cứ điều gì, nhưng sẽ không có bất kỳ nhược điểm nào. Điều đó đang được nói: Dù sao, hãy nâng cấp, vì Server 2008 R2 SP1 (mà tôi hy vọng bạn đang sử dụng) sẽ là EOL từ 2020-01-2014 .

Đối với SQL Server 32 bit / 64 bit: Sự hiểu biết của bạn là chính xác, nếu bạn sẽ không cần> ~ 3,75 GB RAM (hoặc> 2 GB mỗi quá trình), bạn có thể sử dụng phiên bản 32 bit mà không gặp vấn đề gì. Nhưng đối với các phiên bản mới hơn sẽ không có phiên bản 32 bit nào để cài đặt, vì Microsoft chỉ chuyển sang 64 bit.


6
OP đề cập đến "2 GB vào thời gian cao điểm" vì vậy hoàn toàn có khả năng SQL Server muốn sử dụng nhiều hơn 2 GB nhưng không thể do giới hạn quy trình 32 bit.
MonkeyZeus

Có thể là trường hợp, tôi thực sự không biết liệu MS SQL Server 2008 có sử dụng nhiều quy trình cho các tác vụ / trường hợp / cơ sở dữ liệu khác nhau hay không
Lenniey

11

Như đã lưu ý, bạn đang sử dụng HĐH 64 bit. Có hai ưu điểm của việc chuyển sang phiên bản SQL Server 64 bit và một nhược điểm.

Nhược điểm duy nhất là phiên bản SQL Server 64 bit sẽ sử dụng con trỏ 64 bit. Điều này có nghĩa là con trỏ sẽ chiếm gấp đôi bộ nhớ, tiêu thụ gấp đôi băng thông bộ nhớ, v.v. Điều này có thể khá không đáng kể, nhưng nó là một bất lợi. Nó được bù đắp một phần bởi thực tế là việc chuyển sang ứng dụng 64 bit sẽ cho phép bạn bỏ qua chi phí của các ứng dụng 32 bit lớp tương thích phải sử dụng để truy cập các chức năng của hệ điều hành 64 bit.

Ưu điểm chính là nhiều cải tiến đáng kể đã được thực hiện trong tập lệnh CPU được đặt theo thời gian. Một số trong số chúng đã được thực hiện cùng với việc thay đổi thành 64 bit và một số trong số chúng đã được thực hiện trước đó.

Nhưng ngay cả đối với những cái được tạo trước đó, bản dựng 32 bit phải xử lý các CPU không có các tính năng đó và để tránh rắc rối phát hiện và chuyển đổi giữa nhiều phiên bản, chỉ không sử dụng chúng ngay cả khi chúng có mặt. Ví dụ: CPU 64 bit phải có SSE2, nhưng CPU 32 bit có thể không có. Vì vậy, hầu hết mã 32 bit không cần kiểm tra và giả sử không có SSE2. Mã 64 bit được đảm bảo có các hướng dẫn SSE2 và vì vậy sẽ sử dụng nó nếu đó là lựa chọn tốt nhất.

Cái lớn nhất là sự gia tăng số lượng các thanh ghi có mục đích chung được đặt tên từ 8 đến 16. Số lượng các thanh ghi XMM 128 bit cũng được nhân đôi, từ 8 lên 16.

Ngoài ra, một quá trình 64 bit có thể sử dụng một lượng lớn bộ nhớ ảo. Điều này đặc biệt quan trọng với các quy trình truy cập một lượng lớn dữ liệu có cấu trúc trên đĩa. Và, tất nhiên, họ có thể sử dụng các hoạt động số nguyên 64 bit có xu hướng cải thiện hiệu suất mã hóa, nén và thậm chí một số hoạt động của hệ thống tệp trên các hệ thống tệp lớn.


Các hướng dẫn AVX và co có thực sự có tác động đáng chú ý đến hiệu suất của SQL Server không? Tôi sẽ giả định (nhưng tôi chưa bao giờ đánh giá hoặc kiểm tra nó) rằng nó chủ yếu sẽ là hệ thống con IO phụ thuộc vào nó.
Voo

Một số mã 32-bit hiện đại không giả SSE2, đặc biệt khi chạy trên một hệ điều hành mà chỉ hỗ trợ CPU mới đủ để có SSE2 (cùng với một số tính năng cần thiết khác). Tôi giả sử Microsoft biên dịch nội dung của họ với MSVC, có /arch:SSE2tùy chọn mã 32 bit, tương đương với gcc / clang / ICC -msse2. Tôi đoán rằng SQL không có nhiều vòng lặp vectơ SIMD, nhưng sao chép các cấu trúc nhỏ với tải / lưu trữ SIMD 16 byte là tốt.
Peter Cordes

Một trong những thay đổi quan trọng hơn trong x86-64 là địa chỉ liên quan đến PC cho mã độc lập vị trí hiệu quả. Các thư viện PIC 32 bit thường có độ chậm ~ 10% hoặc ~ 15% (IIRC) so với 32 bit không phải PIC. Có nhiều thanh ghi số nguyên cũng giúp rất nhiều. Một lợi thế lớn trong 64 bit là một quy ước gọi đẹp hơn, nhưng trên Windows (không giống như Linux), mã 32 bit sẽ __fastcallvượt qua các đối số trong các thanh ghi cho nhiều chức năng. Quy ước gọi 32 bit của Linux hoàn toàn nằm trên ngăn xếp, do đó, nó khá tào lao đối với các chức năng nhỏ không theo dòng.
Peter Cordes

Nếu vector hóa thực sự ảnh hưởng rất nhiều đến hiệu năng thay vì giả định / yêu cầu một số mức hỗ trợ cụ thể, thì mã có thể đang kiểm tra phiên bản SSE / AVX mới nhất mà CPU hỗ trợ và gọi việc triển khai phù hợp để đạt được tốc độ nhanh như bất kỳ hệ thống nào đang chạy trên.
Dan đang loay hoay bởi Firelight

@DanNeely Điều đó giả định rằng bất cứ ai thực hiện bản dựng đều nỗ lực cải thiện hiệu suất của phiên bản 32 bit. Kinh nghiệm của tôi, ít nhất, là họ thường cho rằng những người quan tâm đến hiệu suất sẽ sử dụng bản dựng 64 bit.
David Schwartz

6

Về cơ bản: Có. Giả sử bạn không bao giờ thực hiện các bản cập nhật chỉ có 4 bit - không chắc chắn thậm chí còn có Máy chủ SQL 32 bit gần đây hơn 2008.

Các vấn đề với câu hỏi của bạn: "Các phiên bản 64 bit cho phép truy cập hơn 4 GB RAM" - làm cho 3gb;) không phải 4. 1gb luôn được bảo lưu.


Nếu chúng ta quá đáng, tại sao không chính xác và đề cập rằng chương trình 32 bit có thể dễ dàng truy cập hàng trăm GB RAM? ;) Chỉ có không gian địa chỉ ảo bị giới hạn.
Voo

3
@Voo: Và SQL Server là một trong số ít các chương trình biết cách.
joshudson

6

Vấn đề tiềm ẩn: Các thư viện DLL của các hàm do người dùng CLR (UDFs) sẽ yêu cầu các phiên bản 64 bit của chúng.

Nếu bạn đang sử dụng thư viện Hàm do người dùng xác định CLR , nó sẽ trở nên không tương thích bit. DLL 32 bit thường không thể được sử dụng trong phần mềm 64 bit và ngược lại. Nếu bạn không thể có phiên bản 64 bit của một số thư viện UDF bạn sử dụng, bạn sẽ mất phần mở rộng cụ thể đó.

Về cơ bản, đây là vấn đề tương tự như nâng cấp bất kỳ phần mềm 32 bit nào với các tiện ích bổ sung lên phiên bản 64 bit. Bạn cũng cần chuyển tất cả các tiện ích bổ sung sang phiên bản 64 bit của chúng. Nói chung là dễ dàng, nhưng vấn đề là ngưng những nơi mà thay thế không có sẵn.


3

Hiệu suất!

Có một số câu trả lời kỹ thuật ở đây, nhưng không cần quá kỹ thuật, và tùy thuộc vào ứng dụng của bạn, bạn sẽ thấy một bản nâng cấp hiệu suất.

Các phần chính là:

Địa chỉ bộ nhớ lớn: Kiến trúc 64 bit cung cấp không gian bộ nhớ trực tiếp lớn hơn. SQL Server 2005 (64 bit) không bị ràng buộc bởi giới hạn bộ nhớ 4 GB của các hệ thống 32 bit. Do đó, có thêm bộ nhớ để thực hiện các truy vấn phức tạp và hỗ trợ các hoạt động cơ sở dữ liệu thiết yếu. Khả năng xử lý lớn hơn này giúp giảm các hình phạt về độ trễ I / O bằng cách sử dụng nhiều bộ nhớ hơn các hệ thống 32 bit truyền thống.

Song song nâng cao: Kiến trúc 64 bit cung cấp khả năng song song và phân luồng nâng cao. Những cải tiến trong xử lý song song và kiến ​​trúc bus cho phép các nền tảng 64 bit hỗ trợ số lượng bộ xử lý lớn hơn (lên đến 64) trong khi cung cấp khả năng mở rộng tuyến tính với mỗi bộ xử lý bổ sung. Với số lượng bộ xử lý lớn hơn, SQL Server có thể hỗ trợ nhiều quy trình, ứng dụng và người dùng hơn trong một hệ thống.

https://teratrax.com/sql-server-64-bit/

Các kết quả ấn tượng nhất mà tôi thấy khi chuyển từ SQL Server 32 bit sang 64 bit (đây là SQL Server 2005) đã tăng khoảng 40% tốc độ trên ứng dụng chính của khách hàng. Tất cả những gì chúng tôi đã làm là cài đặt SQL Server 64 bit, mọi thứ khác đều giống nhau! Đó là một sự gia tăng hiệu suất lớn trong thế giới thực.


-2

Bạn có thể có hiệu suất đa nhiệm tốt hơn, đặc biệt là với các chương trình có đa luồng nặng được tích hợp. Ngoài ra, bạn có thể cài đặt thêm ram với hệ điều hành 64 bit. Nhưng chỉ làm điều này nếu bộ xử lý hỗ trợ các lệnh 64 bit.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.