lỗi Segmentation trong __pthread_getspecific gọi từ libcuda.so.1

Question

Vấn đề: lỗi Segmentation (SIGSEGV, tín hiệu 11)

Giới thiệu tóm tắt chương trình mô tả:

• hiệu suất cao gpu (CUDA) xử lý máy chủ yêu cầu từ xa khách hàng
• mỗi yêu cầu gửi đến sẽ sinh ra một chuỗi thực hiện tính toán trên nhiều GPU (nối tiếp, không song song) và gửi trả lại kết quả cho khách hàng, điều này thường mất từ ​​10-200ms khi mỗi yêu cầu bao gồm hàng chục hoặc hàng trăm cuộc gọi hạt nhân
• yêu cầu trình xử lý có quyền truy cập độc quyền vào GPU, nghĩa là nếu một chuỗi đang chạy trên GPU1 những người khác sẽ phải chờ cho đến khi nó được thực hiện
• biên soạn với -arch = sm_35 -code = compute_35
• sử dụng CUDA 5.0
• tôi không sử dụng bất kỳ Atomics CUDA rõ ràng hoặc bất kỳ rào cản đồng bộ hóa trong hạt nhân, mặc dù i' m sử dụng lực đẩy (các chức năng khác nhau) và cudaDeviceSynchronize() rõ ràng là
• Trình điều khiển Nvidia: NVIDIA dlloader X driver 313,30 Wed 27 Tháng Ba 15:33:21 PDT 2013

OS và thông tin HW:

• Linux lub1 3.5.0-23-generiC# 35 ~ precise1-Ubuntu x86_64 x86_64 x86_64 GNU/Linux
• GPU của: 4x GPU 0: GeForce GTX TITAN
• 32 GB RAM
• MB: ASUS MAXIMUS V EXTREME
• CPU: i7-3770K

thông tin sụp đổ:

sụp đổ xảy ra "ngẫu nhiên" sau một vài ngàn yêu cầu được xử lý (đôi khi sớm hơn, đôi khi sau). dấu vết ngăn xếp từ một số các tai nạn như thế này:

#0 0x00007f8a5b18fd91 in __pthread_getspecific (key=4) at pthread_getspecific.c:62 
#1 0x00007f8a5a0c0cf3 in ??() from /usr/lib/libcuda.so.1 
#2 0x00007f8a59ff7b30 in ??() from /usr/lib/libcuda.so.1 
#3 0x00007f8a59fcc34a in ??() from /usr/lib/libcuda.so.1 
#4 0x00007f8a5ab253e7 in ??() from /usr/local/cuda-5.0/lib64/libcudart.so.5.0 
#5 0x00007f8a5ab484fa in cudaGetDevice() from /usr/local/cuda-5.0/lib64/libcudart.so.5.0 
#6 0x000000000046c2a6 in thrust::detail::backend::cuda::arch::device_properties()() 


#0 0x00007ff03ba35d91 in __pthread_getspecific (key=4) at pthread_getspecific.c:62 
#1 0x00007ff03a966cf3 in ??() from /usr/lib/libcuda.so.1 
#2 0x00007ff03aa24f8b in ??() from /usr/lib/libcuda.so.1 
#3 0x00007ff03b3e411c in ??() from /usr/local/cuda-5.0/lib64/libcudart.so.5.0 
#4 0x00007ff03b3dd4b3 in ??() from /usr/local/cuda-5.0/lib64/libcudart.so.5.0 
#5 0x00007ff03b3d18e0 in ??() from /usr/local/cuda-5.0/lib64/libcudart.so.5.0 
#6 0x00007ff03b3fc4d9 in cudaMemset() from /usr/local/cuda-5.0/lib64/libcudart.so.5.0 
#7 0x0000000000448177 in libgbase::cudaGenericDatabase::cudaCountIndividual(unsigned int, ... 


#0 0x00007f01db6d6153 in ??() from /usr/lib/libcuda.so.1 
#1 0x00007f01db6db7e4 in ??() from /usr/lib/libcuda.so.1 
#2 0x00007f01db6dbc30 in ??() from /usr/lib/libcuda.so.1 
#3 0x00007f01db6dbec2 in ??() from /usr/lib/libcuda.so.1 
#4 0x00007f01db6c6c58 in ??() from /usr/lib/libcuda.so.1 
#5 0x00007f01db6c7b49 in ??() from /usr/lib/libcuda.so.1 
#6 0x00007f01db6bdc22 in ??() from /usr/lib/libcuda.so.1 
#7 0x00007f01db5f0df7 in ??() from /usr/lib/libcuda.so.1 
#8 0x00007f01db5f4e0d in ??() from /usr/lib/libcuda.so.1 
#9 0x00007f01db5dbcea in ??() from /usr/lib/libcuda.so.1 
#10 0x00007f01dc11e0aa in ??() from /usr/local/cuda-5.0/lib64/libcudart.so.5.0 
#11 0x00007f01dc1466dd in cudaMemcpy() from /usr/local/cuda-5.0/lib64/libcudart.so.5.0 
#12 0x0000000000472373 in thrust::detail::backend::cuda::detail::b40c_thrust::BaseRadixSortingEnactor 


#0 0x00007f397533dd91 in __pthread_getspecific (key=4) at pthread_getspecific.c:62 
#1 0x00007f397426ecf3 in ??() from /usr/lib/libcuda.so.1 
#2 0x00007f397427baec in ??() from /usr/lib/libcuda.so.1 
#3 0x00007f39741a9840 in ??() from /usr/lib/libcuda.so.1 
#4 0x00007f39741add08 in ??() from /usr/lib/libcuda.so.1 
#5 0x00007f3974194cea in ??() from /usr/lib/libcuda.so.1 
#6 0x00007f3974cd70aa in ??() from /usr/local/cuda-5.0/lib64/libcudart.so.5.0 
#7 0x00007f3974cff6dd in cudaMemcpy() from /usr/local/cuda-5.0/lib64/libcudart.so.5.0 
#8 0x000000000046bf26 in thrust::detail::backend::cuda::detail::checked_cudaMemcpy(void* 

Như bạn có thể thấy, thông thường nó kết thúc trong __pthread_getspecific gọi từ libcuda.so hoặc đâu đó trong thư viện riêng của mình. Theo tôi nhớ, chỉ có một trường hợp không bị lỗi mà thay vào đó nó bị treo theo cách lạ: chương trình có thể trả lời các yêu cầu của tôi nếu chúng không liên quan đến tính toán GPU (số liệu thống kê, v.v.) tôi không bao giờ có một câu trả lời. Ngoài ra, làm nvidia-smi -L không hoạt động, nó chỉ treo ở đó cho đến khi tôi khởi động lại máy tính. Nhìn tôi như một loại bế tắc của GPU. Đây có thể là một vấn đề hoàn toàn khác so với vấn đề này.

Có ai có manh mối về sự cố hoặc điều gì có thể gây ra điều này không?

Cập nhật:

Một số các phân tích thêm:

• cuda-memcheck không in bất kỳ thông báo lỗi.
• valgrind - kiểm tra rò rỉ không in khá một vài bài viết, giống như dưới đây (có hàng trăm như thế):

==2464== 16 bytes in 1 blocks are definitely lost in loss record 6 of 725 
==2464== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==2464== by 0x568C202: ??? (in /usr/local/cuda-5.0/lib64/libcudart.so.5.0.35) 
==2464== by 0x56B859D: ??? (in /usr/local/cuda-5.0/lib64/libcudart.so.5.0.35) 
==2464== by 0x5050C82: __nptl_deallocate_tsd (pthread_create.c:156) 
==2464== by 0x5050EA7: start_thread (pthread_create.c:315) 
==2464== by 0x6DDBCBC: clone (clone.S:112) 
==2464== 
==2464== 16 bytes in 1 blocks are definitely lost in loss record 7 of 725 
==2464== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==2464== by 0x568C202: ??? (in /usr/local/cuda-5.0/lib64/libcudart.so.5.0.35) 
==2464== by 0x56B86D8: ??? (in /usr/local/cuda-5.0/lib64/libcudart.so.5.0.35) 
==2464== by 0x5677E0F: ??? (in /usr/local/cuda-5.0/lib64/libcudart.so.5.0.35) 
==2464== by 0x400F90D: _dl_fini (dl-fini.c:254) 
==2464== by 0x6D23900: __run_exit_handlers (exit.c:78) 
==2464== by 0x6D23984: exit (exit.c:100) 
==2464== by 0x6D09773: (below main) (libc-start.c:258) 

==2464== 408 bytes in 3 blocks are possibly lost in loss record 222 of 725 
==2464== at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==2464== by 0x5A89B98: ??? (in /usr/lib/libcuda.so.313.30) 
==2464== by 0x5A8A1F2: ??? (in /usr/lib/libcuda.so.313.30) 
==2464== by 0x5A8A3FF: ??? (in /usr/lib/libcuda.so.313.30) 
==2464== by 0x5B02E34: ??? (in /usr/lib/libcuda.so.313.30) 
==2464== by 0x5AFFAA5: ??? (in /usr/lib/libcuda.so.313.30) 
==2464== by 0x5AAF009: ??? (in /usr/lib/libcuda.so.313.30) 
==2464== by 0x5A7A6D3: ??? (in /usr/lib/libcuda.so.313.30) 
==2464== by 0x59B205C: ??? (in /usr/lib/libcuda.so.313.30) 
==2464== by 0x5984544: cuInit (in /usr/lib/libcuda.so.313.30) 
==2464== by 0x568983B: ??? (in /usr/local/cuda-5.0/lib64/libcudart.so.5.0.35) 
==2464== by 0x5689967: ??? (in /usr/local/cuda-5.0/lib64/libcudart.so.5.0.35) 

Thông tin thêm:

Tôi có đã thử chạy trên ít thẻ hơn (3, vì đó là mức tối thiểu cần thiết cho chương trình) và sự cố vẫn xảy ra.

Điều trên không đúng, tôi đã định cấu hình sai ứng dụng và sử dụng cả bốn thẻ. Việc chạy lại các thử nghiệm với 3 thẻ thực sự dường như giải quyết được sự cố, nó hiện đang chạy trong vài giờ với tải nặng mà không bị treo. Bây giờ tôi sẽ cố gắng để nó chạy nhiều hơn một chút và sau đó có thể thử sử dụng một tập hợp con khác gồm 3 thẻ để xác minh điều này và đồng thời kiểm tra xem sự cố có liên quan đến một thẻ cụ thể hay không.

Tôi theo dõi nhiệt độ GPU trong khi chạy thử và dường như không có gì sai. Các thẻ nhận được lên đến khoảng 78-80 ° C dưới tải cao nhất với quạt đi vào khoảng 56% và điều này vẫn cho đến khi tai nạn xảy ra (vài phút), dường như không quá cao đối với tôi. Một điều tôi đã suy nghĩ về là cách các yêu cầu được xử lý - có khá nhiều cuộc gọi cudaSetDevice, vì mỗi yêu cầu sinh ra một chuỗi mới (tôi đang sử dụng thư viện mongoose) và sau đó luồng này chuyển đổi giữa các thẻ bằng cách gọi cudaSetDevice (id) với id thiết bị thích hợp. Việc chuyển đổi có thể xảy ra nhiều lần trong một yêu cầu và tôi không sử dụng bất kỳ luồng nào (vì vậy tất cả đều chuyển sang luồng mặc định (0) IIRC). Điều này có thể liên quan đến các sự cố xảy ra trong pthread_getspecific không?

Tôi cũng đã thử nâng cấp lên trình điều khiển mới nhất (beta, 319,12) nhưng điều đó không giúp ích gì.

Answer 1

Nếu bạn có thể xác định 3 thẻ hoạt động, hãy thử đạp thẻ thứ 4 thay cho một trong 3 thẻ và xem bạn có gặp lại lỗi không. Đây chỉ là xử lý sự cố tiêu chuẩn mà tôi nghĩ. Nếu bạn có thể xác định một thẻ duy nhất, khi được bao gồm trong nhóm 3 người, vẫn còn nêu ra vấn đề, thì thẻ đó là nghi ngờ.

Nhưng, đề xuất của tôi để chạy với ít thẻ hơn cũng dựa trên ý tưởng rằng nó có thể làm giảm tải tổng thể trên PSU. Ngay cả ở 1500W, bạn có thể không có đủ nước trái cây. Vì vậy, nếu bạn quay vòng thẻ thứ 4, thay cho một trong số 3 (nghĩa là vẫn chỉ giữ 3 thẻ trong hệ thống hoặc định cấu hình ứng dụng của bạn để sử dụng 3) và bạn sẽ không gặp lỗi, sự cố có thể là do sức mạnh tổng thể 4 thẻ.

Lưu ý rằng mức tiêu thụ điện năng của GTX Titan ở mức đầy tải có thể lên tới 250W hoặc có thể nhiều hơn. Vì vậy, có vẻ như PSU 1500W của bạn sẽ ổn, nhưng có thể phân tích cẩn thận về lượng điện DC có sẵn trên mỗi đường ray và cách bo mạch chủ và PSU khai thác đường truyền 12V DC tới mỗi GPU.

Vì vậy, nếu giảm xuống 3GPUs dường như khắc phục được sự cố bất kể bạn sử dụng 3 vấn đề nào, tôi đoán là PSU của bạn không hoạt động. Không phải tất cả 1500W đều có sẵn từ một đường ray DC. Các "đường sắt" 12V thực sự bao gồm một số đường ray 12V khác nhau, mỗi trong số đó cung cấp một phần nhất định của 1500W tổng thể. Vì vậy, mặc dù bạn có thể không được kéo 1500W, bạn vẫn có thể quá tải một đường sắt duy nhất, tùy thuộc vào cách sức mạnh GPU được kết nối với đường ray.

Tôi đồng ý rằng nhiệt độ trong phạm vi 80C sẽ ổn, nhưng điều đó cho biết (xấp xỉ) GPU đã được nạp đầy đủ, vì vậy nếu bạn nhìn thấy trên tất cả 4 GPU cùng một lúc thì bạn sẽ phải chịu tải nặng.