이 페이지에서는 자주 발생하는 문제에 대한 해결 방법과 안내를 제공합니다. 이 가이드를 계속 확장하면서 더 다양한 상황을 다룰 수 있도록 문제 해결 관련 주제를 지속적으로 추가할 예정입니다.
커뮤니티와 공유하고 싶은 Weave 문제 해결 팁이 있으신가요? 이 가이드 하단의 Edit this page를 클릭해 pull request를 제출하면 직접 기여할 수 있습니다.
50입니다. UI에서 행 수를 줄이거나 쿼리 매개변수를 사용해 조정할 수 있습니다.
Traces 페이지 오른쪽 하단의 Per page 컨트롤을 사용해 표시되는 행 수를 조정하세요. 기본값인 50 외에도 10, 25, 100으로도 설정할 수 있습니다.
수동 방식을 선호한다면, 쿼리 URL에서 pageSize 쿼리 매개변수를 최대값인 100보다 작은 값으로 변경하면 됩니다.
Weave는 동일한 쿼리를 반복 실행하거나 제한된 네트워크 대역폭 환경에서 작업할 때 성능을 향상시키기 위해 서버 응답 캐싱을 제공합니다. 현재는 기본적으로 비활성화되어 있지만, 향후 릴리스에서는 이 기능이 기본 동작이 될 예정입니다.
서버 응답 캐싱은 다음과 같은 경우에 특히 유용합니다.
- 동일한 쿼리를 자주 실행하는 경우
- 네트워크 대역폭이 제한적인 경우
- 지연 시간이 긴 환경에서 작업하는 경우
- 오프라인 환경에서 개발하면서 나중에 사용하기 위해 응답을 캐싱해 두고 싶은 경우
이 기능은 데이터셋에 대해 반복 평가를 수행할 때 특히 유용하며, run 사이에서 데이터셋을 캐싱해 둘 수 있습니다.
캐싱을 활성화하려면 다음 환경 변수를 설정하세요:
# 서버 응답 캐싱 활성화
export WEAVE_USE_SERVER_CACHE=true
# 캐시 크기 제한 설정 (기본값은 1GB)
export WEAVE_SERVER_CACHE_SIZE_LIMIT=1000000000
# 캐시 디렉터리 설정 (선택 사항, 기본값은 임시 디렉터리)
export WEAVE_SERVER_CACHE_DIR=/path/to/cache
obj_readtable_querytable_query_statsrefs_read_batchfile_content_read
캐시 크기는 WEAVE_SERVER_CACHE_SIZE_LIMIT(바이트 단위)로 제어됩니다. 실제로 사용되는 디스크 공간은 다음 세 가지 구성 요소로 구성됩니다:
- 고정된 32KB 체크섬 파일
- 실행 중인 클라이언트당 최대 약 4MB까지 증가하는 Write-Ahead Log(WAL) 파일 (프로그램 종료 시 자동 삭제됨)
- 최소 32KB, 최대
WEAVE_SERVER_CACHE_SIZE_LIMIT인 메인 데이터베이스 파일
총 사용 디스크 공간:
- 실행 중: >= 32KB + 약 4MB + 캐시 크기
- 종료 후: >= 32KB + 캐시 크기
예를 들어, 캐시 한도가 5MB인 경우:
- 실행 중: 최대 약 9MB
- 종료 후: 최대 약 5MB
때때로 Weave UI에서 큰 트레이스 데이터가 부분적으로 잘리는 경우가 있습니다. 이 문제는 기본 트레이스 출력이 Weave가 직렬화하는 방법을 알지 못하는 원시 커스텀 Python 객체이기 때문에 발생합니다.
큰 트레이스 데이터가 잘리지 않도록, 모든 트레이스 데이터를 반환할 수 있도록 문자열로만 구성된 사전을 정의하세요.
import weave
class MyObj:
def __init__(self, x: int):
self.x = x
def __repr__(self):
return f"MyObj(x={self.x})"
def to_dict(self):
return {"x": self.x}
@weave.op()
def make_my_obj():
x = "s" * 10_000
return MyObj(x)
client.flush()를 호출하면 모든 백그라운드 작업이 메인 스레드에서 처리되도록 강제하여, 메인 스레드 실행 동안 병렬 처리가 이루어지도록 보장합니다. 이는 사용자 코드 실행이 서버로의 데이터 업로드가 완료되기 전에 끝나는 경우 성능을 향상시킬 수 있습니다.
예시:
client = weave.init("fast-upload")
# ... 평가 설정
result = evaluation.Evaluate(dataset_id="my_dataset_id")
client.flush()
WEAVE_CLIENT_PARALLELISM: 병렬 처리에 사용할 수 있는 스레드 수입니다. 이 값을 늘리면 병렬 처리를 위해 사용 가능한 스레드 수가 증가하여, 데이터셋 업로드와 같은 백그라운드 작업의 성능이 향상될 수 있습니다.
이는 weave.init()의 settings 인수를 사용해 코드에서 설정할 수도 있습니다:
client = weave.init("fast-upload", settings={"client_parallelism": 100})
[Errno 24]: Too many open files
PIL을 사용하며, 프로그램이 실행되는 동안 파일 디스크립터를 열어 둔 상태로 유지합니다.
이 문제를 해결하려면 ulimit을 사용해 열 수 있는 파일 수에 대한 시스템 한도를 65,536으로 늘리세요:
Weave는 애플리케이션 성능에 미치는 영향을 최소화하기 위해 백그라운드 스레드에서 트레이스 데이터를 업로드합니다. 그러나 멀티프로세싱이나 Celery 같은 태스크 큐/워커 프로세스를 사용할 때, 워커 프로세스가 백그라운드 스레드가 트레이스를 모두 업로드하기 전에 종료되면 트레이스 데이터가 손실됩니다.
워커 프로세스에서 데이터 손실을 방지하려면, 워커 태스크가 완료되기 전에 client.flush() 또는 client.finish()를 호출하여 백그라운드 업로드가 완료되도록 해야 합니다.
이 메서드들은 서로 다른 목적을 가집니다:
weave.flush(): 단순하고 조용한 플러시. Weave를 워커 프로세스나 CI 환경에 통합할 때 권장됩니다.weave.finish(): 진행률 바나 상태 콜백을 통해 진행 상황 피드백을 제공합니다. 대화형 스크립트나 노트북에 권장됩니다.
두 메서드는 모두 모든 백그라운드 업로드가 완료될 때까지 블로킹하므로, 워커 프로세스가 종료될 때 트레이스 데이터가 손실되지 않도록 보장합니다.
다음 예시는 client.finish()를 보여 줍니다:
from celery import Celery
import weave
app = Celery('tasks')
@app.task
def process_task(input_data):
weave.init("your-team-name/your-project-name")
try:
# 트레이스를 생성하는 태스크 로직
result = your_processing_function(input_data)
# 태스크 완료 전에 모든 트레이스가 업로드되었는지 확인
weave.finish()
return result
finally:
pass
with 컨텍스트 매니저를 사용하면 종료 시 weave.finish()가 자동으로 호출되도록 할 수도 있습니다.
with weave.init("your-team-name/your-project-name") as client:
result = your_processing_function(input_data)
return result
weave.flush()를 사용하여 애플리케이션의 성능을 개선할 수도 있습니다. 자세한 내용은 Flushing을 참고하세요. 
플랫폼
W&B Models
W&B Weave
W&B Inference
W&B 트레이닝
릴리스 노트