Cách tối ưu hóa phân trang cho lớn trong cơ sở dữ liệu bộ nhớ

Question

Tôi có một ứng dụng mà toàn bộ cơ sở dữ liệu được thực hiện trong bộ nhớ bằng cách sử dụng một bản đồ stl cho mỗi bảng trong cơ sở dữ liệu.

Mỗi mục trong sơ đồ stl là một đối tượng phức tạp có tham chiếu đến các mục khác trong các bản đồ stl khác.

Ứng dụng hoạt động với một lượng lớn dữ liệu, do đó, nó sử dụng hơn 500 MByte RAM. Khách hàng có thể liên hệ với ứng dụng và nhận phiên bản được lọc của toàn bộ cơ sở dữ liệu. Điều này được thực hiện bằng cách chạy qua toàn bộ cơ sở dữ liệu và tìm các mục có liên quan cho khách hàng.

Khi ứng dụng đã chạy trong một giờ hoặc lâu hơn, Windows 2003 SP2 sẽ bắt đầu trang ra các phần của RAM cho ứng dụng (Mặc dù có RAM 16 GB trên máy).

Sau khi ứng dụng đã được phân trang một phần thì đăng nhập của khách hàng mất một thời gian dài (10 phút) vì bây giờ nó tạo ra lỗi trang cho từng tra cứu con trỏ trong bản đồ. Nếu chạy máy khách đăng nhập lần thứ hai ngay sau đó thì nó nhanh (vài giây) vì tất cả bộ nhớ giờ đã trở lại trong RAM.

Tôi có thể thấy rằng có thể yêu cầu Windows khóa bộ nhớ trong RAM, nhưng điều này thường chỉ được đề xuất cho trình điều khiển thiết bị và chỉ dành cho bộ nhớ "nhỏ".

Tôi đoán một giải pháp mans nghèo có thể là lặp qua toàn bộ cơ sở dữ liệu bộ nhớ, và do đó cho Windows biết chúng tôi vẫn quan tâm đến việc giữ datamodel trong RAM.

Tôi đoán một giải pháp người nghèo khác có thể là vô hiệu hóa tệp trang hoàn toàn trên Windows.

Tôi đoán giải pháp tốn kém sẽ là cơ sở dữ liệu SQL, sau đó viết lại toàn bộ ứng dụng để sử dụng lớp cơ sở dữ liệu. Sau đó, hy vọng hệ thống cơ sở dữ liệu sẽ thực hiện có nghĩa là để truy cập nhanh.

Có các giải pháp thanh lịch nào khác không?

Answer 1

Điều này âm thanh như rò rỉ bộ nhớ hoặc một vấn đề phân mảnh nghiêm trọng. Dường như với tôi rằng bước đầu tiên sẽ là tìm ra nguyên nhân gây ra 500 Mb dữ liệu để sử dụng 16 GB RAM và vẫn muốn nhiều hơn nữa.

Chỉnh sửa: Windows có tông đơ đặt làm việc tích cực cố gắng loại bỏ dữ liệu không sử dụng. Ý tưởng cơ bản là nó đi qua và đánh dấu các trang là có sẵn, nhưng để lại dữ liệu trong chúng (và trình quản lý bộ nhớ ảo biết dữ liệu nào nằm trong chúng). Tuy nhiên, nếu bạn cố gắng truy cập vào bộ nhớ đó trước khi nó được cấp phát cho các mục đích khác, nó sẽ được đánh dấu là đang được sử dụng một lần nữa, điều này thường sẽ ngăn không cho nó bị phân trang.

Nếu bạn thực sự nghĩ đây là nguồn gốc của sự cố, bạn có thể gián tiếp kiểm soát tông đơ đặt làm việc bằng cách gọi SetProcessWorkingSetSize. Ít nhất là trong kinh nghiệm của tôi, điều này chỉ hiếm khi được sử dụng nhiều, nhưng bạn có thể ở trong một trong những tình huống bất thường khi nó thực sự hữu ích.

Answer 2

---- Sửa

Với snakefoot giải thích, vấn đề được trao đổi ra bộ nhớ mà không được sử dụng cho một thời gian dài hơn và do này không có dữ liệu trong bộ nhớ khi cần thiết.Điều này tương tự như thế này:

Can I tell Windows not to swap out a particular processes’ memory?

và chức năng VirtualLock nên làm công việc của mình:

http://msdn.microsoft.com/en-us/library/aa366895(VS.85).aspx

---- câu trả lời trước

Trước hết bạn cần phải phân biệt giữa bộ nhớ bị rò rỉ và bộ nhớ cần vấn đề.

Nếu bạn bị rò rỉ bộ nhớ thì sẽ là nỗ lực lớn hơn để chuyển đổi toàn bộ ứng dụng sang SQL hơn là gỡ lỗi ứng dụng.

SQL không thể nhanh hơn khi được thiết kế tốt, cơ sở dữ liệu trong bộ nhớ cụ thể trong miền và nếu bạn có lỗi, rất có thể bạn sẽ có các phiên bản khác nhau trong phiên bản SQL.

Nếu đây là vấn đề về bộ nhớ, thì bạn sẽ cần phải chuyển sang SQL và điều này nghe có vẻ như là một khoảnh khắc tốt.

Answer 3

Như @Jerry Coffin cho biết, thực sự có vẻ như vấn đề thực tế của bạn là rò rỉ bộ nhớ. Sửa lỗi đó.

Nhưng đối với hồ sơ, không có "giải pháp mans nghèo" nào của bạn sẽ hoạt động. Ở tất cả.

Windows sẽ xóa một số dữ liệu của bạn vì không có chỗ cho nó trong RAM. Lặp qua toàn bộ cơ sở dữ liệu bộ nhớ sẽ tải trong mỗi byte của mô hình dữ liệu, có ... điều này sẽ khiến các phần khác của nó được phân trang. Cuối cùng, bạn sẽ tạo ra rất nhiều lỗi trang, và sự khác biệt duy nhất ở cuối sẽ là mà các phần của cấu trúc dữ liệu được phân trang.

Tắt tệp trang? Có, nếu bạn nghĩ rằng một vụ tai nạn cứng là tốt hơn so với hiệu suất thấp. Windows không có dữ liệu trang vì nó thú vị. Nó làm điều đó để xử lý các tình huống mà nếu không nó sẽ hết bộ nhớ. Nếu bạn vô hiệu hóa pagefile, ứng dụng sẽ chỉ sụp đổ khi nó sẽ trang ra dữ liệu.

Nếu tập dữ liệu của bạn thực sự lớn đến mức không vừa trong bộ nhớ, thì tôi không thấy lý do tại sao cơ sở dữ liệu SQL đặc biệt "đắt". Không giống như giải pháp hiện tại của bạn, cơ sở dữ liệu được tối ưu hóa cho mục đích này. Chúng có nghĩa là xử lý các tập dữ liệu quá lớn để phù hợp với bộ nhớ, và để làm điều này một cách hiệu quả.

Có vẻ như bạn bị rò rỉ bộ nhớ. Sửa chữa đó sẽ là giải pháp thanh lịch, hiệu quả và chính xác.

Nếu bạn không thể làm điều đó, sau đó, hoặc

• ném thêm RAM vào vấn đề (ứng dụng kết thúc sử dụng 16GB? Ném 32 hoặc 64GB vào nó sau đó), hoặc
• chuyển sang một định dạng được tối ưu hóa để truy cập đĩa hiệu quả (Cơ sở dữ liệu SQL có thể)

Answer 4

Chúng tôi có một vấn đề tương tự và giải pháp chúng tôi chọn là phân bổ mọi thứ trong khối bộ nhớ dùng chung. AFAIK, Windows không trang này ra. Tuy nhiên, bằng cách sử dụng stl-map ở đây không phải là cho trái tim mờ nhạt và vượt quá những gì chúng tôi yêu cầu.

Chúng tôi đang sử dụng Boost Shared Memory để thực hiện việc này cho chúng tôi và nó hoạt động tốt.Thực hiện theo các ví dụ chặt chẽ và bạn sẽ được thiết lập và chạy một cách nhanh chóng. Boost cũng có Boost.MultiIndex sẽ thực hiện rất nhiều thứ bạn muốn.

Để có giải pháp sql miễn phí, bạn đã xem Sqlite chưa? Họ có một tùy chọn để chạy như một cơ sở dữ liệu trong bộ nhớ.

Chúc may mắn, có vẻ như là một ứng dụng thú vị.

Answer 5

Tôi có một ứng dụng mà toàn bộ cơ sở dữ liệu được thực hiện trong bộ nhớ sử dụng một STL-bản đồ cho mỗi bảng trong cơ sở dữ liệu .

Đó là sự bắt đầu của kết thúc: STL's std :: map cực kỳ thiếu bộ nhớ. Tương tự áp dụng cho std :: list. Mỗi phần tử sẽ được phân bổ riêng biệt gây ra lãng phí bộ nhớ khá nghiêm trọng. Tôi thường sử dụng std :: vector + sort() + find() thay vì std :: map trong các ứng dụng có thể (nhiều tìm kiếm hơn sửa đổi) và tôi biết việc sử dụng bộ nhớ trước có thể trở thành vấn đề.

Khi ứng dụng đã được chạy cho một giờ hoặc lâu hơn, sau đó Windows 2003 SP2 bắt đầu trang ra các bộ phận của RAM cho các ứng dụng (Cho dù có 16 Gbyte RAM trên máy tính này).

Khó nói mà không biết cách viết đơn của bạn. Windows có tính năng để tải xuống từ bộ nhớ RAM bất kỳ bộ nhớ của các ứng dụng nhàn rỗi có thể được dỡ xuống. Nhưng điều đó thường ảnh hưởng đến các tập tin được ánh xạ bộ nhớ và giống nhau.

Nếu không, tôi thực sự khuyên bạn nên đọc lên Windows memory management documentation. Nó không phải là rất dễ hiểu, nhưng Windows có tất cả các loại và các loại bộ nhớ có sẵn cho các ứng dụng. Tôi không bao giờ có may mắn với nó, nhưng có lẽ trong ứng dụng của bạn bằng cách sử dụng tùy chỉnh std :: allocator sẽ làm việc.

Answer 6

Tôi có thể tin rằng đó là lỗi của hành vi pagefile không hoàn thiện - tôi đã chạy máy tính xách tay của tôi chủ yếu là với pagefile tắt kể từ nt4.0. Theo kinh nghiệm của tôi, ít nhất là lên đến XP Pro, Windows đột nhập hoán đổi các trang chỉ để cung cấp lợi ích đáng ngờ khi có phần mở rộng thực sự chậm đến không gian làm việc tối đa.

Yêu cầu trao đổi lợi ích nào với đĩa cứng là đạt được với 16 Gigabity RAM thực có sẵn? Nếu công việc của bạn lớn đến mức cần nhiều bộ nhớ ảo hơn +10 Gigs, thì một khi hoán đổi là các quy trình bắt buộc thực tế sẽ mất nhiều thời gian hơn, lâu hơn hàng nghìn lần để hoàn thành. Trên Windows, bộ nhớ cache của hệ thống tập tin không thể thay đổi dường như đối nghịch với các mối quan hệ.

Bây giờ khi tôi (rất) có dịp hết bộ công việc trên máy tính xách tay XP của tôi, không có kẹt xe, ứng dụng tội lỗi chỉ gặp sự cố. Một tiện ích để tạm dừng các quá trình xử lý bộ nhớ trước thời gian đó và làm cho một cảnh báo sẽ tốt đẹp, nhưng không có điều như vậy chỉ là một sự vi phạm, một vụ tai nạn, và đôi khi explorer.exe đi xuống quá.

Pagefiles - những người cần em '