niepozwole

MongoDB na przełomie lat przeszło naprawdę sporo zmian. Pracuję z tą bazą od przeszło wersji 2.4 (lub nawet 2.2). Przyznam początki były ciężkie, sporo rzeczy nie działało albo działało inaczej niż przedstawiała to dokumentacja. Początkowo sam sharding również był drzazgą w oku, dane trzeba było podzielić praktycznie "ręcznie" wykorzystując pre splitting. Po wprowadzeniu dzielenia danych po hashu sam sharding jest praktycznie bezbolesny. Dodatkowo od wersji 3.2 nowy silnik wiredTiger staje się używalny (wcześniej było to jeszcze mocno niezgrane). Jeśli w Twoim środowisku jest zarówno sporo zapisów jak i odczytów to polecam zainwestować w dyski SSD (są bardzo pomocne przy sporej liczbie operacji zapisu). Dyski SSD do odczytów nie mają aż takiego znaczenia, ponieważ większość z Twojego aktualnego working seta i tak wyląduje w ramie. Także jeśli masz chęci i siły to polecam spróbować, nie taki diabeł straszny jak go malują.

Czy ja wiem? Raczej nie bardzo. Chodziło mi o rozwiązanie tego problemu w możliwie nieinwazyjny sposób. Debian np. instalując paczki PHP (bo dobrze wiemy skąd pochodzą pliki w stylu sess_) dodaje specjalny wpis do crona czyszczący cyklicznie pliki sesji. Wystarczy odpowiednio skonfigurować php.ini, ewentualnie uprawnienia do katalogu z sesjami zamiast dodawać nadmiarowe crony.

Przede wszystkim o jakim systemie operacyjnym mówimy?

Napisałeś, że widzisz białą stronę. Czy te wpisy dotyczące permission denied już się nie pojawiają w logach? Jeśli przestały się pojawiać, to jeden problem rozwiązałeś, ale trafiłeś na następny. Sprawdź co widać w /var/log/php5-fpm.log. Dodatkowo w php.ini włącz zapisywanie error_loga do pliku.

Wydaje mi się, że szukasz takiego rozwiązania: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/s1-bind-rndc.html

Sprawdzałeś logi binda? Wygląda, że wystartował poprawnie. Z tego co wkleiłeś problem jest z narzędziem dig, a nie z bindem. Na jakim serwerze to odpalasz? Czy jest to serwer wirtualny? Jeśli tak to podbij pamięć i sprawdź ustawienia w /etc/security/limits.conf.

Ten problem może również pojawić się w przypadku braku uprawniń do wykonania konkretnej operacji. Na przykład możesz mieć taką sytuację, że podajesz poprawne dane logowania (user i pass), ale użytkownik, na którego się logujesz nie ma uprawnień do bazy danych na której chesz wykonywać operacje.

Ja ze swojej strony polecam dodanie opcji read_only do konfiguracji MySQL na serwerze SLAVE. Tak dla pewności, że baza jest na pewno tylko do odczytu. :-)

Niestety ekspertem od FreeBSD nie jestem dlatego dalej nie pomogę, natomiast przykładowo w Debianie, żeby to poprawnie działało muszą być załadowane dwa moduły: nf_nat_ftp 1516 0 nf_conntrack_ftp 5252 1 nf_nat_ftp

Uwierzytelnianie działa, jest natomiast problem jakby z przesyłaniem już konkretnych danych. Po samej procedurze uwierzytelnienia komunikacja przestawia się na tryb pasywny i jest problem z samym przesyłaniem danych już po nawiązaniu połączenia. Jesteś pewien, że po stronie serwera lub u Ciebie nie ma żadnej zapory blokującej ruch? Wątpię abyś blokował u siebie ruch wychodzący (tryb pasywny), natomiast serwer musi mieć możliwość otwarcia dowolnego portu i komunikacji przez niego. Możesz również ustalić określony zakres portów wpisując go to pliku PassivePortRange. Więcej o trybach komunikacji FTP znajdziesz tutaj.

To nie zmienia faktu, że w takim wypadku baza mysql jest u Ciebie wąskim gardłem. Warto przyjrzeć się tematowi i nawet jeśli nie chcesz optymalizować to chociaż popracować nad indeksami. To może być ciekawa przygoda. :-)

W tym wycinku strace nie widać nic niepokojącego (komunikat Timeout jest raczej standardem i powinien spływać dosyć często). Natomiast wpis, który wkleiłeś ze slow loga jest niepokojący: zapytanie zwróciło tylko 1000 rekordów a zostało przeanalizowane 64842158. Zdecydowanie na tej tabeli, z której pochodzi wpis brakuje dobrego indeksu.

Jeżeli podejrzewasz problem ze słabą optymalizacją zapytań to polecam włączyć slow query log. Wszystko opisane jest tutaj: https://dev.mysql.com/doc/refman/5.5/en/slow-query-log.html. Do pliku zostaną zrzucone zapytania wolniejsze niż czas jaki ustawisz. Dodatkowo znajdą się tam cenne informacje odnośnie buforów, indeksów itd. Taki plik slow loga polecam również przepuścić przez narzędzie: http://www.percona.com/doc/percona-toolkit/2.2/pt-query-digest.html. Znacznie ułatwia analizę danych oraz robi ładne podsumowania. Jeszcze mała wskazówka: nic nie stoi na przeszkodzie abyś ustawił czas na 0, wtedy zostaną zalogowane wszystkie zapytania. :-)

Na pierwszy rzut oka obstawiłbym to: Temporary tables created on disk: 42% (11K on disk / 26K total) Sprawdź co podczas zwiększonego obciążenia konkretnie robi serwer MySQL. Przydatne będzie polecenie: https://dev.mysql.com/doc/refman/5.5/en/show-status.html Być może w tym czasie MySQL tworzy sobie dużą liczbę małych tabel tymczasowych, dlatego nie jesteś w stanie tego wyłapać. Dodatkowo polecam również podczas obciążenia odpalić narzędzie mytop z interwałem czasowym 1s. Zapytania mogą być bardzo szybkie, być może tak uda Ci się je wychwycić.

Dodatkowo warto połączyć ze sobą dwa narzędzia: traceroute i mtr. Raporty z tych narzędzi dadzą Tobie pełniejszy obraz. W sieci znajdziesz sporo informacji jak interpretować ich wyniki.