php 편집기 Youzi는 Spring Data JPA 흐름 모니터링에 대한 Java 질문과 답변을 제공합니다. 개발 중에 데이터 흐름을 실시간으로 모니터링하는 것은 시스템 성능 최적화 및 문제 해결에 매우 중요합니다. 이 기사에서는 Spring Data JPA 흐름을 모니터링하여 데이터 처리 프로세스를 더 잘 이해하고 적시에 문제를 감지하고 그에 따라 처리하는 방법을 소개합니다. Spring Data JPA 흐름을 효과적으로 모니터링하고 시스템 안정성과 성능을 향상시키는 방법에 대해 논의해 보겠습니다!
이 블로그에 설명된 대로 Spring 데이터 JPA 스트리밍을 사용하려고 합니다. 하지만 로그를 통해 프로세스나 진행 상황을 모니터링할 수는 없습니다. 프로세스가 일괄적으로 데이터를 추출하려고 할 때 로그에 여러 SQL 쿼리가 인쇄되어야 합니까? 그렇지 않다면 모든 행이 한 번에 로드되지 않았다는 것을 어떻게 알 수 있습니까?
다른 블로그(예: 이 블로그 및 이 블로그)에서는 mysql을 hint_fetch_size
设置为 integer.min_value
로 변환해야 한다고 제안했는데, 이것이 해결책일 수 있다고 생각했지만 이로 인해 다음 예외가 발생합니다.
2024-01-29 14:40:20.843 경고 78247 --- [nio-8080-exec-1] o.h.engine.jdbc.spi.sqlExceptionhelper: sql 오류: 0, sqlstate: s1000 2024-01-29 14:40:20.843 오류 78247 --- [nio-8080-exec-1] o.h.engine.jdbc.spi.sqlExceptionhelper: 스트리밍 결과 세트 com.mysql.cj.protocol.a.result. 4ca63fa5는 아직 활성 상태입니다. 스트리밍 결과 세트가 열려 있고 지정된 연결에서 사용 중인 동안에는 명령문이 발행되지 않습니다. 더 많은 쿼리를 시도하기 전에 활성 스트리밍 결과 세트에 대해 .close()를 호출했는지 확인하세요. 종료 시간: 48 org.springframework.orm.jpa.jpasystemException: 결과 집합을 추출할 수 없습니다. 중첩된 예외는 org.hibernate.Exception.genericjdbcException입니다. 결과 집합을 추출할 수 없습니다. org.springframework.orm.jpa.vendor.hibernatejpadialect.converthibernateaccessException(hibernatejpadialect.java:331)에서
내 저장소 코드는 다음과 같습니다.
으아악직접 스트리밍 성능을 안정적으로 모니터링할 수 없기 때문에 위의 내용이 Spring 데이터 JPA에서 스트림 쿼리를 사용하는 올바른 방법인지 보증을 받고 싶습니다.
업데이트
위 예외는 동일한 호출 메소드에서 findallstream 메소드를 반복적으로 호출하여 발생합니다. 그 중 하나를 제거하면 예외가 해결되었습니다.
데이터를 일괄적으로 가져오는 중인지 표시하는 로그 구성을 찾을 수 없습니다. 하지만 로컬에서 성능을 테스트하는 방법을 찾았습니다.
스트리밍 기능을 테스트하려면 수백만 개의 레코드가 포함된 데이터베이스에 액세스해야 합니다. 저는 mysql 직원 데이터를 사용하기 위해 도커 이미지 https://www.php.cn/link/7092d5eb1bbca1a22bdc69ba3f517e68를 사용합니다
Docker 이미지를 설정한 후 mysql Workbench와 서버를 연결하는 데 문제가 있습니다. Docker 이미지가 기본적으로 SSL 연결을 허용하도록 구성되지 않은 것 같습니다. 연결을 설정하려면 use ssl
플래그를 비활성화해야 했습니다. 이 설정은 SSL 탭 아래의 mysql 워크벤치에 나타납니다.
애플리케이션의 연결 문자열도 다음과 같이 구성되어야 합니다.
으아악직원 데이터베이스의 데이터는 약 280만 행을 포함하는 salaries
라는 테이블로 구성됩니다.
테스트를 위해 저장소 클래스에 다음 메소드가 있는 작은 Spring 데이터 JPA 애플리케이션과 이러한 메소드를 호출하는 간단한 컨트롤러를 작성했습니다.
으아악그런 다음 읽은 데이터를 json 개체로 변환하는 작은 코드를 작성한 다음 여러 스레드를 사용하여 이를 파일에 다시 썼습니다. 이는 실제 사례에서 처리를 시뮬레이션하기 위한 것입니다.
내가 관찰한 것은 이것이다.
목록 방식을 사용하면 메모리 사용량이 크게 늘어납니다. 초기 쿼리에는 대부분의 시간이 걸렸지만 모든 데이터가 로드되고 나면 실제 데이터 처리가 빠르게 완료되었습니다.
스트림 방식을 사용할 때 메모리 사용량에 미치는 영향은 거의 눈에 띄지 않습니다. 하지만 전체적으로 완성 처리 부분의 성능은 리스트 방식과 비슷하거나 더 나쁘다.
결론
위의 결과를 통해 저장소 접근 방식이 stream
返回类型仅应在存在内存不足风险时使用,即获得 out 内存异常
이라는 결론을 내릴 수 있었습니다. 그렇지 않고 애플리케이션이 이미 충분히 큰 서버에서 실행되고 있는 경우 메모리 사용량에 대한 전반적인 영향은 거의 눈에 띄지 않으며 프로세스가 빠르게 완료되는 경우에만 일시적입니다.
intellij 프로파일러의 메모리 사용량 통계
위 내용은 Spring Data JPA 스트림을 모니터링하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!