발전생

heroku 512MB 무료 서버에 만들어놓은 리뷰 분석 프로젝트를 올리기 위해 끙끙대고 있다. 거의 일주일 동안 배포에만 매진하고 있고 여러 가지 경우의 수들을 테스트 중이다. 매우 많은 경우의 수를 테스트해본 뒤에도 메모리에 개선이 없자 더는 경우의 수를 생각해낼 수 없었다. 그래서 이건 뭔가 고질적인 문제가 있다는 생각 하에 celery task가 돌아가는 중에 사용되는 메모리를 알아야겠다는 생각이 들었다. 진작 이걸 찾아봤어야 했다. 아래 코드만으로도 변수가 사용 중인 메모리(memory)를 확인할 수 있다. import sys sys.getsizeof(변수명) 사용 중인 변수들의 메모리를 확인해 보니 예상치도 못한 결과가 나왔다. 가장 큰 메모리를 차지하고 있던 건 리스트도 아니고 pandas가..

꼬꼬마가 konlpy 태거 중에 품사 태깅 결과가 가장 마음에 들었었다. 그러나 문제는 이를 heroku에 배포 시 2000MB가 넘는 메모리를 사용하며 E15 에러와 함께 뻗어버린다는 것이다. heroku에서는 무료 서버가 아닌 돈을 지불하는 서버도 1000MB는 꽤나 고가이다. 그렇기 때문에 꼬꼬마가 태깅 실력이 좋다 했도 사용할 수가 없다. konlpy memory를 검색어로 구글에 검색을 했을 때 kkma 메모리가 연관 검색어로 뜰만큼 kkma는 메모리를 많이 차지한다. 심지어 꼬꼬마 공식 홈페이지에도 메모리 얘기가 나와있다. 꼬꼬마 한글 형태소 분석기는 Java 라이브러리로써 jar 파일 형태로 배포한다. 배포하는 jar 파일을 내려받아 형태소 분석기를 사용할 프로젝트의 classpath에 이 ..

[정정] 어떤 optimizer가 좋다고 확정하기 어렵다. 모델이 다른 가중치, 다른 테스트 케이스를 사용했기 때문에 정확하다고 말할 수 없다. [참고로 konlpy tag 중 Okt를 사용해 감성 분류, Kkma를 사용해 키워드 추출을 했다] keras의 optimizer 중에 rmsprop과 adam이 그나마 단점을 잘 보완한 애들이라고 배웠다. adam은 rmsprop에 학습 step까지 조절한 꽤나 훌륭한 optimizer라고 알고 있었다. 그래서 당연히 adam(아담) 짱을 외치며 adam을 optimizer로 선택했었다. 그런데 긍정, 부정 예측에 있어서 만족스럽지 못한 결과를 금방 얻어 버렸다. 캡처를 깜빡했지만 adam으로 학습한 결과 아래 문장 '오버핏이라 핏은 이쁘게 촤악 나오긴한다.'..

무신사 리뷰의 한 문장으로 mecab을 제외하고 모든 tag에 대해 품사 추출을 해보았다. 리뷰 분석에 있어서 신조어나 사전에 등록되어 있지 않은 단어도 하나의 품사로 취급되기를 원했다. 리뷰 문장을 참으로 많이 살펴봤지만 대부분 띄어쓰기가 나름 잘 되어있다. 그래서 조사 앞, 띄어쓰기 뒤에 있는 단어는 전부 하나로 취급해줬으면 했다. 위에 결과를 보면 kkma가 그나마 내 요구 조건을 잘 충족시켜 줬다. 하지만 속도는 저 짧은 문장에 대해서도 억 소리 나게 느렸다. 꼬꼬마(kkma)야. 속도 좀 어떻게 안 되겠니? customized_konlpy 사용도 염두에 뒀다. 그런데 2018년 이후 customized_konlpy가 개발이 중단돼서 그런지 최신 okt보다 품사 태깅 능력이 많이 떨어진다. okt..

TypeError: 'Manager' object is not callable 에러를 몇 번 봤다. 왜 계속 같은 실수를 하는 지 모르겠다. 저 에러를 보면 왠지 Manager 관련해서 손을 좀 봐줘야 할 것만 같다. ModelManager를 만든다든지. 하지만 절대 아니다. 나는 항상 저 에러를 발견할 때마다 내가 objects를 잘못 썼다는 것을 알았다. objects는 모델의 속성이다. objects()가 아니다. 즉 함수가 아니다. 잘못된 코드 review = Review.objects().only('watch').get(id=review_id) 올바른 코드 review = Review.objects.only('watch').get(id=review_id)

def get_object(self): review = super().get_object() # 조회수 1 증가 review.watch += 1 review.save() return review 이와 같이 객체를 가져와서 속성을 변경한 뒤 저장(update)을 하는 로직이다. 그런데 무려 4ms나 걸린다. 어떻게든 줄여야겠다는 생각이 든다. DetailView라서 watch 속성만 가져오는 건 불가능하다. name을 비롯해 여러 속성이 보여야 한다. 생각을 해보다가 마땅한 방법이 없어서 celery가 나중에 처리해주는 방식을 선택했다. 덕분에 update query 작업이 없어져서 6ms -> 2ms로 로딩 속도를 줄일 수 있었다. def get_object(self): review = super().g..

흠... query에 연결은 1번만 하지만 10 simillar가 거슬린다. 최적화시켜 본다. 우선 query 가져오는 시간부터 살펴봤다. 데이터 10개 가져오는데 8.97ms나 필요하다. 개선이 필요해 보인다. 일단 인덱스 페이지에서 나는 info만을 필요로 한다. Review.objects.order_by('-create_date')[:5] 그래서 위 코드를 아래처럼 Review.objects.only("info").order_by('-create_date')[:5] info 관련 필드만 가져오게 수정했다. only() 사용만으로도 5.99ms로 줄어들었다. 새로고침 해보니까 같은 코드임에도 매번 다른 시간이 걸린다. 이 시간에 크게 연연하면 안 되겠다. 하지만 아직도 거슬린다. 10 similar ..

tensorflow 최신 버전으로 아무 생각 없이 깔고 로컬에서 잘 구동하는 걸 확인 했다. 그래서 heroku에 배포에도 잘 될 줄만 알았다. "error: failed to push some refs to" 그래서 이게 도대체 무슨 말인가? 싶어서 해당 에러를 복사해서 구글에 검색을 해봤다. 어느 블로그에서는 commit이 문제가 있어서라고 했다. 근본적인 문제는 이게 아니었다. heroku의 해당 app에 들어가보니 build failed가 적혀 있었다. 그래서 view build log를 클릭 했더니 맨 아랫줄에서 문제의 원인을 찾을 수 있었다. Compiled slug size: 616.2M is too large (max is 500M) 500M까지 가능한데 필요한 파이썬 패키지 설치에서 10..

잘 되던 걸 배포 준비하다가 jpype1을 삭제하고 다시 깔았었다. 그랬더니 okt가 java 파일 경로를 못 읽는 문제가 발생했다. 다행히 전에 헤매던 기억이 있었는지 금방 오류를 잡을 수 있었다. 로컬 컴퓨터에 깔려있는 jpype1이랑 같은 버전을 django의 가상환경에 설치했더니 다행히 다시 정상 작동한다. jpype1의 로컬 버전이랑 같게 설치하자.

현재 리뷰 프로젝트를 진행하면서 리뷰 파일을 csv로 만들고 데이터베이스에 업로드 시키고 pandas의 read_csv로 읽게 했다. 물론 모든 곳에 encoding='utf-8' cp949 인코딩도 안 되는 것인가? 이 문제는 리뷰에 섞여있는 이모티콘(emoji) 때문에 발생했다고 추측 중이다. 일부 리뷰에는 문제 없이 잘 작동하는 걸로 보아 cp949 인코딩이 해석할 수 없는 문자(이모티콘)가 들어가서 이런 문제가 발생한 듯 하다. UnicodeEncodeError: 'cp949' codec can't encode character '\U0001f44d' in position 431: illegal multibyte sequence open(file, mode='r', buffering=-1, enc..