Làm thế nào tôi có thể tối ưu hóa tốc độ cho tốc độ?

Tôi đang sử dụng pgrouting trên cơ sở dữ liệu postgis được tạo thông qua osm2pgrouting. Nó thực hiện rất tốt trên một tập dữ liệu giới hạn (3,5k cách, tất cả các đường dẫn ngắn nhất A * tìm kiếm <20 ms).

Tuy nhiên, vì tôi đã nhập một hộp giới hạn lớn hơn (122 nghìn cách) từ europe.osm, hiệu suất đã giảm đi rất nhiều (một con đường ngắn nhất có giá khoảng 900ms).

Tôi sẽ nghĩ rằng việc sử dụng A * hầu hết các cạnh đó sẽ không bao giờ được truy cập khi chúng ở ngoài đường.

Những gì tôi đã làm cho đến nay trong một nỗ lực để cải thiện tốc độ:

• Đặt một chỉ mục trên cột hình học (không có hiệu ứng đáng chú ý)
• Tăng bộ nhớ của tôi từ 8GB lên 16GB
• Thay đổi cài đặt bộ nhớ postgresql (shared_buffers, effect_cache_size) từ (128MB, 128MB) thành (1GB, 2GB) (không có hiệu ứng đáng chú ý)

Tôi có cảm giác rằng hầu hết các công việc đang được thực hiện trong thư viện C Boost, nơi đồ thị đang được thực hiện để tối ưu hóa postgresql sẽ không cho tôi kết quả tốt hơn nhiều. Khi tôi thực hiện các thay đổi nhỏ đối với nhóm hàng tôi chọn cho A * cho mỗi tìm kiếm, tôi hơi sợ rằng thư viện boost không thể lưu trữ biểu đồ của tôi và phải xây dựng lại tất cả các cạnh 122k mỗi lần (mặc dù nó sẽ chỉ sử dụng rất tập hợp con giới hạn mọi truy vấn). Và tôi không biết bao nhiêu chi tiêu để làm điều đó so với tìm kiếm con đường ngắn nhất thực tế.

Có ai trong số các bạn sử dụng pgrouting trên bộ dữ liệu OSM 122k trở lên không? Tôi nên mong đợi hiệu suất nào? Những cài đặt nào ảnh hưởng đến hiệu suất nhất?

Khi phải đối mặt với các nhiệm vụ như thế này, mục tiêu chính của bạn là hợp lý. Đừng thay đổi thông số dựa trên 'cảm giác ruột'. Mặc dù ruột dường như hoạt động cho Hollywood nhưng nó không dành cho chúng ta sống trong thế giới thực. Chà, ít nhất không phải ruột của tôi ;-).

Bạn nên:

1. thiết lập một số liệu có thể sử dụng và có thể lặp lại (như thời gian được yêu cầu bởi một truy vấn mở rộng)

2. lưu kết quả số liệu trong một bảng tính và tính trung bình chúng (loại bỏ tốt nhất và tồi tệ nhất). Điều này sẽ cho bạn biết nếu những thay đổi bạn đang thực hiện đang đi đúng hướng

3. giám sát máy chủ của bạn bằng cách sử dụng top và vmstat (giả sử bạn đang bật * nix) trong khi các truy vấn đang chạy và tìm kiếm các mẫu quan trọng: nhiều io, cpu cao, trao đổi, v.v. Nếu cpu đang chờ i / o thì hãy cố gắng cải thiện hiệu suất đĩa (điều này nên dễ dàng, xem bên dưới). Nếu CPU thay vào đó là 100% mà không có bất kỳ hoạt động nào đáng kể trên đĩa, bạn phải tìm cách cải thiện truy vấn (điều này có lẽ sẽ khó hơn).

Để đơn giản, tôi cho rằng mạng không đóng vai trò quan trọng nào ở đây.

Cải thiện hiệu suất cơ sở dữ liệu

Nâng cấp lên phiên bản Postgres mới nhất. Phiên bản 9 tốt hơn nhiều so với các phiên bản trước. Nó là miễn phí nên bạn không có lý do gì phải không.

Đọc cuốn sách tôi đề nghị đã ở đây .

Bạn thực sự nên đọc nó. Tôi tin rằng các chương liên quan cho trường hợp này là 5,6,10,11

Cải thiện hiệu suất đĩa

1. Nhận một ổ đĩa SSD và đặt toàn bộ cơ sở dữ liệu vào nó. Hiệu suất đọc nhiều khả năng sẽ tăng gấp bốn lần và hiệu suất ghi cũng sẽ cải thiện triệt để

2. gán thêm bộ nhớ cho postgres. Lý tưởng nhất là bạn có thể chỉ định đủ bộ nhớ để toàn bộ (hoặc phần nóng nhất) có thể được lưu vào bộ nhớ, nhưng không quá nhiều để xảy ra hoán đổi. Trao đổi là rất xấu. Điều này được đề cập trong cuốn sách được trích dẫn trong đoạn trước

3. vô hiệu hóa atime trên tất cả các đĩa (thêm tùy chọn noatime vào fstab)

Cải thiện độ hoàn hảo của truy vấn

Sử dụng các công cụ được mô tả trong sách được trích dẫn ở trên để theo dõi truy vấn / tìm kiếm của bạn và tìm các điểm dừng đáng để tối ưu hóa.

Cập nhật

Sau khi nhận xét tôi đã xem mã nguồn cho thủ tục được lưu trữ

https://github.com/pgRouting/pgrouting/blob/master/core/src/astar.c

và dường như một khi truy vấn đã được điều chỉnh thì sẽ không còn nhiều chỗ để cải thiện vì thuật toán chạy hoàn toàn trong bộ nhớ (và thật không may, chỉ trên một cpu). Tôi e rằng giải pháp duy nhất của bạn là tìm một thuật toán tốt hơn / nhanh hơn hoặc một thuật toán có thể chạy đa luồng và sau đó tích hợp nó với các postgres bằng cách tạo một thư viện như pgrouting hoặc sử dụng một số phần mềm trung gian để lấy dữ liệu (và có thể lưu trữ bộ đệm) đưa nó vào thuật toán.

HTH

Tôi có cùng một vấn đề và sắp hỏi về danh sách gửi thư, cảm ơn mọi người!

Tôi đang sử dụng Chụp sao với một triệu rưỡi hàng trên bảng định tuyến. Phải mất gần mười giây để tính toán nó. Với 20k hàng phải mất gần ba giây. Tôi cần Chụp sao vì tôi cần hạn chế rẽ.

Dưới đây là một số ý tưởng tôi đang cố gắng thực hiện:

• Trên SQL, nơi pgRouting có được các cách, hãy sử dụng st_buffer để nó không có mọi cách, mà chỉ là các cách "gần đó":

  chọn * từ shortest_path_sh Boot_star ('CHỌN CHỌN. * TỪ định tuyến định tuyến, (chọn st_buffer (st_en phong (st_collect (hình học)), 4) làm hình học từ định tuyến trong đó id =' | | source_ || 'hoặc id =' | | target | | ') e WHERE Rout.geometry && e.geometry', nguồn, đích, true, true);

Nó đã cải thiện hiệu năng, nhưng nếu cách cần đi ra ngoài bộ đệm, nó có thể trả về lỗi "không tìm thấy đường dẫn", vậy ... bộ đệm lớn? vài cuộc gọi tăng bộ đệm cho đến khi nó tìm thấy một cách?

• Các tuyến nhanh được lưu trữ

Giống như dassouki đề xuất, tôi sẽ lưu trữ một số tuyến đường "hữu ích" để nếu khoảng cách quá dài, nó có thể đi qua các tuyến đường nhanh này và chỉ cần tìm đường vào và ra.

• Bảng phân vùng theo chỉ số gis

Nhưng tôi cho rằng, nếu nó đi vào bộ nhớ, nó không thực sự quan trọng ... Dù sao đi nữa, nên kiểm tra nó.

Xin vui lòng, tiếp tục gửi bài nếu bạn tìm thấy một ý tưởng khác.

Ngoài ra, bạn có biết nếu có một số pgRouting được biên dịch cho Postgres9 không?

Chúng tôi vừa tạo một nhánh trong git cho một lối đi ngắn nhất bị giới hạn lần lượt @ https://github.com/pgRouting/pgrouting/tree/trsp

Xin lỗi chưa có tài liệu nào, nhưng nếu bạn đặt câu hỏi trong danh sách pgRouting, tôi sẽ ở đó và sẽ trả lời. Mã này chạy nhanh hơn nhiều so với ngôi sao băng và dựa trên thuật toán Dijkstra.

-Steve

Tôi có một bảng lộ trình nguồn chứa ~ 1200000 cạnh. Trên i7 của tôi với SSD, phải mất 12 giây để tạo tuyến đường. Ý tưởng của tôi để tăng hiệu suất là chia bảng cạnh thành nhiều bảng mức thu phóng. Tôi có nghĩa là mức độ giống hệt với gạch google. Ở mức thu phóng thứ 8, ví dụ, tôi có 88 bảng. Mỗi bảng chứa một tập hợp con đường và các khu vực của chúng chồng lên nhau để tính toán một tuyến đường giữa hai điểm nằm cách nhau không quá 290 km mất 2 giây. Ở thời điểm tính toán cấp 9 giảm xuống 0,25 giây và chúng ta có 352 bảng. Giải trí của tất cả các biểu đồ trong trường hợp chúng tôi chỉnh sửa đường mất không quá một giờ. Cách triệt để để tăng tốc độ định tuyến là sử dụng thuật toán Floyd-Warshall. Nhưng không ai biết phải mất bao nhiêu để tính ma trận tiền thân trên rất nhiều cạnh.