qubaaa

Po aktualizacji reverse DNS onet nie wrzuca już do spamu. Wszystko zatem w porządku. Dziękuję za tę informację. Pozdrawiam.

Domniemam, że na hetznerze jest to reverse DNS entry przy adresie IP mojego serwera? Dzięki za odpowiedź. Pozostaje mi czekać aż zmiany wejdą w życie i testować dalej.

Witam. Na początku zaznaczę, że poczytałem sieć oraz forum na ten temat, jednak nie do końca rozwiązałem problem. Proszę o sprawdzenie, czy domena miodek.org ma poprawne ustawienia, jeśli chodzi o mailing. Póki co sprawdziłem spf oraz zadbałem o poprawne fqdn. W konfiguracji postfixa nie wykonywałem żadnych większych zmian. Po szybkich testach wniosek taki, że maile najwyraźniej poprawnie docierają do gmaila, interii, gazety oraz o2. Mam niestety problem z onetem. Mail wysyła się natychmiastowo, jednak od razu ląduje w spamie. Co jeszcze mogę zrobić? Jest gdzieś w sieci jakiś konkretny artykuł o polityce antyspamowej onetu? Niestety duży procent osób porejestrowanych u mnie ma tam skrzynki. Dodam jeszcze, że w mailu jako nadawca oraz reply-to podaję inny adres (wiążący się z konkretną stroną, a hostuję ich na tej maszynie kilka) niż ten, z którego wysyła postfix (www-data@miodek.org). Czy takie działanie ma jakies minusy (widzę, że gmail do pierwszego maila dodaje od: adresstrony przez adresmailera). Ustawienie takiej samej domeny nadawcy jak i domeny mailera nie sprawiło, że onet przestał wrzucać maile do spamu, tak więc myślę, że to tutaj nie gra jakieś większej roli prócz ta informacyjna dla użytkownika. Oczywiście domena nadawcy oraz ta z której wysyła postfix są na tym samym IP. Domena korzysta również z google apps, ale tę sprawę chyba załatwiłem poprawnym rekordem txt? Proszę o jakieś delikatne nakierowanie, co jeszcze mogę zrobić. Pozdrawiam.

Istotnie bardzo ładnie zboczyliście z tematu, jednakże przynajmniej coś z tego mogłem wyciągnąć. Weryfikuję wasze domysły: na serwerze mam prawie wyłącznie skrypty napisane w php, obsługujące bazę mysql. Konfiguracja była bardzo standardowa - apache2 + mod_php + mysql. Moja konkluzja tutaj jest taka, że zamiast żyłować tę maszynę, mogę ją zmienić na posiadającą 8GB DDR3 (obednie 2GB DDR2) w niemalże tej samej cenie. Mimo wszystko poczekam, bo póki co sytuacja się trochę ustabilizowała. Gdyby ktoś miał jeszcze pomysł, co można tutaj poprawić, to chętnie wysłucham. Skoro konfiguracja nie różni się wiele od domyślnej, to wnioskuję, że można tutaj jeszcze coś poradzić. Pozdrawiam i dziękuję za dotychczasową dyskusję.

Nie korzystam z cache'ującego proxy. Akceleratorem jest apc. Pomyślę nad varnishem, gdy optymalizacja konfiguracji nie da efektów. Po lekturze paru źródeł szczerze powiedziawszy mam wątpliwości czy żarcie swapu zostało spowodowane za dużą, czy za małą wartością maxclients. Błąd z error loga sugeruje, że jest to za mała liczba. Maszyna o której mowa ma zaledwie 2GB RAMu. Biorąc pod uwagę fakt, że są to w 90% skrypty php, zakładam że na jeden poromny proces przypada 10 MB. Dzieląc ram przez tą liczbę mam lekko ponad 200. Przyjmując, że maszyna sama z siebie już trochę ramu zjada ze względu na inne odpalone procesy, ustawilem maxclients na 175. Poprzednia wartość wynosiła 150. Obecna konfiguracja mpm workera: <IfModule mpm_worker_module> StartServers 2 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxClients 175 MaxRequestsPerChild 10000 </IfModule>

Na tyle także wpadłem. Chodzi mi jednak o kwestię zachowania serwera. Czy zamiast zżerać cały ram i swap, nie powinien on po prostu klientom ponad normę wyświetlać informacji, że strona nie może zostać wyświetlona?

Zaktualizowałem kernela oraz całe oprogramowanie. Efektem jest brak segfaultów oraz szybsze działanie strony. Niestety problem zwiech nie zniknął. Jedyną rzeczą, jaką zaobserwowałem w logach podczas ziechy (jako zwiechy rozumiem bardzo duze czasy oczekiwania na reakcje serwera - zjada on wtedy 100% swapu i ramu) jest taki oto błąd: [Mon Oct 03 10:10:21 2011] [error] server reached MaxClients setting, consider raising the MaxClients setting

Tak, ale gdyby tego nie logował, to dalej pozostaje problem zwiech. Serwer potrafi się zakrztusić 2 razy dziennie. Serwer teraz przy normalnej pracy je jakies 700MB RAM, obciążenie rdzeni 50-60%. Nierzadko skacze na 100% i utrzymuje się na tym poziomie przez kilka sekund.

Witam. Serwer niedawno zaliczył 2 lata uptime bez większych ingerencji z mojej strony. Niestety od jakiegoś czasu obserwuję w logach nieciekawe wiadomości: Sep 26 19:28:59 ns310834 grsec: From 207.46.204.224: Segmentation fault occurred at (null) in /usr/sbin/apache2[apache2:31961] uid/euid:81/81 gid/egid:81/81, parent /usr/sbin/apache2[apache2:23531] uid/euid:0/0 gid/egid:0/0 Sep 26 19:28:59 ns310834 grsec: From 207.46.204.224: signal 11 sent to /usr/sbin/apache2[apache2:31944] uid/euid:81/81 gid/egid:81/81, parent /usr/sbin/apache2[apache2:23531] uid/euid:0/0 gid/egid:0/0 by /usr/sbin/apache2[apache2:31961] uid/euid:81/81 gid/egid:81/81, parent /usr/sbin/apache2[apache2:23531] uid/euid:0/0 gid/egid:0/0 Czasami dochodzi też drugi objaw: serwer kompletnie zmula do tego stopnia, że parę minut zajmuje się zalogowanie na niego. Wszystko wraca do normy po restarcie apache. Nie mam pojęcia, czy ma to związek z segfaultami - ale niestety nie mogę tego wykluczyć. Niestety poza tym w logach nie ma nic niepokojącego. Ruch na stronie mam obecnie dość przeciętny, w ciągu tych 2 lat bywał on o 25% większy. Po access logu widzę, że googlebot jest dość aktywny, ale nie sądzę, by aktywność ta była większa niż zazwyczaj. Co ciekawe obecnie głupia kompilacja php wrzuca takie kwiatki do loga: Sep 26 22:17:16 ns310834 conftest[4169]: segfault at 1 ip 00000000004054d4 sp 00007fff895731b0 error 4 in conftest[400000+a2000] Sep 26 22:17:16 ns310834 grsec: From 89.174.34.11: Segmentation fault occurred at 0000000000000001 in /var/tmp/portage/dev-lang/php-5.3.8/work/sapis-build/cli/conftest[conftest:4169] uid/euid:0/0 gid/egid:0/0, parent /var/tmp/portage/dev-lang/php-5.3.8/work/sapis-build/cli/configure[configure:4168] uid/euid:0/0 gid/egid:0/0 Oczywiście zrobiłem testy cpburnem, memtestem oraz fsck. Hardware jest w porządku.

Zmieniłem myhostname z dns-u serwera na konkretną domenę podpiętą pod serwer i już filtry gmaila to przepuszczają.

Dla potomnych - nie testujcie postfixa skrzynką gmaila - a jeśli już, to pamiętajcie, że tam jest folder spam. Już wiem, czemu nie ma maili w kolejce i logi nic nie wskazują - po prostu wszystko działa jak należy.

Witam, wiem - dużo było o tym tematów, jeszcze więcej ich chyba przeczytałem i nic. Stawiam sobie serwer www pod gentoo, póki co wszystko działa jak należy, oprócz tego nieszczęsnego postfixa. Chcę zmusić funkcję php mail() do wysyłania maili. Obecnie sprawa wygląda tak: wywołanie mail() zwraca true, poczta nie dochodzi, nie pojawiają się żadne logi w /var/log/mail.*, mailq puste. Dokonałem tylko standardowej konfiguracji (myhostname), z tego co zdołałem wyczytać więcej nie jest potrzebne, by zaczęło to choć w jakimś stopniu działać. postfixa oczywiście wystartowałem poprzez /etc/init.d/postfix start Ktoś wie w czym może tkwić problem? Żeby chociażby jakieś logi zwróciło. Zaznaczam, że nie mam w tej gestii doświadczenia, więc można domniemać, że popełniam banalne błędy. Dodaje polaczenie z telnetem: