Pan Kot

Po co Ci logi jak odpalasz aplikację w screen? Przecież masz całą historię w oknie. A jak potrzebujesz dodatkowo czegoś takiego to zainteresuj się tee.

Nie powinieneś do tego używać php-fpm tylko własnej usługi podpiętej pod systemd czy cokolwiek czego tam używasz jako init, nawet jeśli będzie to głupie polecenie typu php /sciezka/do/twojego/skrypt.php. FPM się do tego całkowicie nie nadaje.

Na pewno nic globalnego - mój bot pięknie trzyma połączenie ze Steamem od 2-3 dni, ale ja sam też na chwilę straciłem, więc pewno coś na linii FR-PL.

Czego się spodziewasz po gościu w domenie @managerseo

A zyski z robienia sobie czarnego PR na forum i usilnego udowadniania, że nie warto robić z wami żadnych interesów bo nawet nie jesteście w stanie wydać złotówki za poświęconą przez kogoś pracę rozumiem, że będą - w porządku, to na pewno dobry pomysł szukać jeleni na forum takim jak WHT, powodzenia w biznesie życzę . Mam wrażenie, że wysłaliście tu kogoś kto robi za taką samą stawkę jak ta proponowana .

SIGINT to interrupt, SIGTERM to termination. Żaden z nich nie gwarantuje, że w ogóle aplikacja się zakończy, bo to w gestii procesu leży obsługa tych sygnałów i reakcja na nie - sygnał, który kończy proces to SIGKILL, SIGTERM jedynie prosi proces o zakończenie się (i bezpieczne zamknięcie właśnie). Różnicy między tymi dwoma dużej nie ma, ale SIGINT to sygnał, który jest wysyłany w momencie CTRL+C na aplikacji w foregroundzie właśnie, a SIGTERM jest niejako "zewnętrzny". Wszystkie aplikacje powinny obsługiwać te sygnały w taki sam sposób, bo obydwa proszą aplikację o zamknięcie, ale przyjęło się, że wysyła się SIGTERM'a, a SIGINT jest właśnie na potrzeby CTRL+C (dlatego, że ten sygnał może być wysłany ze standardowego wejścia właśnie).

Strasznie sobie słabe forum wybraliście na szukanie jeleni. Próbowaliście na jakimś forum "serwerowni cs:go"?

Czy zmniejszenie ładowania elementu X z 10 ms do 5 ms przyspieszy mi stronę gdy element Y ładuje się 10 sekund? NIE. A żeby odpowiedzieć sobie na to pytanie trzeba najpierw zlokalizować co jest najwoleniejsze, a potem optymalizować, a nie optymalizować w ciemno. Profilowanie to podstawa optymalizacji, jak chcesz optymalizować bez profilowania albo testów to równie dobrze możesz rzucić kostką, bo końcowy efekt może być gorszy od początkowego - i w tym przypadku może tak być, bo szyfrowanie generuje overhead, a nie przyspiesza (z definicji, SPDY i inne cuda pomijamy, nawet jeśli overhead jest minimalny to nadal jest).

Tak bym zrobił, jakby OVH rzeczywiście oferowało w produkcyjnej ofercie produkcyjne serwery - ale to było z góry oznaczone jako OVH discovery + ukryte w tradycyjnej ofercie, i każdy z własnej nieprzymuszonej woli się w to pakował, więc nie widzę potrzeby współczucia . Co nie zmienia faktu, że jednocześnie się cieszę, że coś się rusza, bo może sam bym przeniósł zabawki z Francji do Polski, ale jak już to co tam się dzieje będzie można nazwać produkcją. A do tego czasu... Nawet boty wiedzą lepiej co dla nich dobre .

A co mają jeleni rozpieszczać - sami się na płatne beta testy zapisaliście .

Pewnie, że tak - każdy kij ma dwa końce, choć w tym przypadku pewno wystarczy zgłosić i naprawią, skoro to regresja.

To jest bardzo fajne rozwiązanie bo lepiej i łatwiej się integruje coś co już działa, ma dobrą dokumentację + API, niż pisanie od zera tego samego. Poza tym duża część odpowiedzialności za łatanie, naprawianie, poprawianie i wsparcie leży po stronie rozwiązania, a ty masz się tylko dostosować do API i swojego własnego kodu, co też sporo poprawia końcowy efekt w kwestii wsparcia i poprawek. Sam paneli ani GUI do nich nie robię, ale mam od cholery projektów, w których całość to 10% mojego kodu, i 90% definicji API kilkunastu serwisów. I nie jest to tak, że idę na łatwiznę - to działa lepiej niż jakbym re-implementował to samo co ktoś już dawno zrobił, i to dużo lepiej. Nie wyobrażam sobie pisania np. własnego konwertera walut, kiedy mogę spytać o kursy Yahoo czy cokolwiek innego co mi pasuje.

Jak mogłem o gicie i dockerze zapomnieć, dodane .

Tak, jest ważny i bez RAIDa żadnego serwera bym nie brał. Tak, do gier lepszy będzie SYS z serii GAME, ale z racji braku RAIDa raczej sam bym się na niego nie pokusił, a raczej na coś z RAIDem. i7-SSD-1 brzmi dobrze, mimo że nie ma anty-ddos game - chyba, że nie chcesz i7 i wystarczy Ci xeon, to masz prawie za pół ceny.

Ani 0 ani domyślny w okolicach 60 nie jest dobry. Prawidłowe ustawienie serwerowe waha się w widełkach od 1 do 10, w zalezności od setupu.

http://www.webhostingtalk.pl/topic/56150-jak-zaczac-praktycznie-nauke-na-admina/?do=findComment&comment=481480

Tak, ale przy wykryciu takich rzeczy przez RTM, serwer Ci nie leci w tryb rescue. Serwer leci w tryb rescue przy wykryciu konkretnego ruchu sieciowego, i jeśli RTM jest dostępny/zainstalowany, dodatkowo w mailu dostajesz notkę z jego ostatniego reportu, który może pomóc Ci w naprawieniu problemu. Dlatego właśnie pisze, że usuwając RTM jedynie sam możesz sobie zaszkodzić, bo OVH ma głęboko gdzieś czy go używasz czy nie, a anti-hack nie jest w ogóle od niego zależny.

Serio sądzisz, że RTM jest odpowiedzialny za hack detection? OVH nie musi wiedzieć co masz na serwerze, i w wielu przypadkach nie wiedzą, bo mają lepsze rzeczy do roboty niż włamywanie się na serwery klientów. RTM jest dla Ciebie, i możesz sobie sam podejrzeć co reportuje bo output leci na konsolę - możesz również go sobie wyłączyć, ale sam na tym tracisz.

ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 100 100 016 Pre-fail Always - 0 2 Throughput_Performance 0x0005 136 136 054 Pre-fail Offline - 92 3 Spin_Up_Time 0x0007 125 125 024 Pre-fail Always - 185 (Average 182) 4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 41 5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0 7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail Always - 0 8 Seek_Time_Performance 0x0005 115 115 020 Pre-fail Offline - 34 9 Power_On_Hours 0x0012 096 096 000 Old_age Always - 31002 10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 41 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 135 193 Load_Cycle_Count 0x0012 100 100 000 Old_age Always - 135 194 Temperature_Celsius 0x0002 181 181 000 Old_age Always - 33 (Min/Max 24/44) 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0 Wszystko zależy od tego co dysk przez te 20k godzin robił - jestem pewny, że mój jeszcze drugie tyle pociągnie .

Bez dokładnej rozpiski co było ruszane nie ma opcji oszacować jak bardzo awaryjny dany dysk będzie. Co więcej, nawet z rozpiską jest to trudne bo wadliwe sztuki zdarzają się wszędzie, włącznie z nówkami, dlatego też osobiście mam większe zaufanie do takiego dysku co ma przepracowane 20k godzin i jest w perfekcyjnym stanie niż do nówki bezpośrednio z pudełka, której nikt nie testował.

Panele: ISPConfig, Vesta, opcjonalnie Webmin Web serwery: Nginx, Apache, opcjonalnie Lighttpd PHP: FPM (nginx), worker (Apache), opcjonalnie HHVM SQL: MariaDB, MySQL, opcjonalnie PostgreSQL Języki: Bash (obowiązkowo), PHP, opcjonalnie perl/python (perl jest trochę nieżywy już więc polecam pythona) Monitoring: Zabbix, Nagios, opcjonalnie Munin DNS: Bind, opcjonalnie dnsmasq (caching) Firewall: iptables, opcjonalnie ufw/bastille Security: fail2ban, ssh, sftp, pojęcie chroot/jail, LXC, opcjonalnie jailkit Wirtualizacja: KVM, LXC (po raz drugi), Docker, Proxmox, opcjonalnie Xen/OpenVZ Poczta: Postfix, Dovecot, Spamassassin, clamd, rainloop, opcjonalnie exim4 SSL: Let's encrypt, różnice między typami certyfikatów (dlaczego jednak nie let's encrypt do wszystkiego?) Systemy: Debian, Ubuntu, CentOS, Archlinux, FreeBSD i różnice między nimi, opcjonalnie Gentoo Optymalizacja: memcached, varnish, cloudflare Kontrola wersji: Git (obowiązkowo), opcjonalnie mercurial/subversion Automatyzacja: Ansible, opcjonalnie SaltStack/Puppet/Chef Opcjonalnie: Non-SQL: MongoDB, Riak, Cassandra Kernel: Linux, Grsecurity, kompilacja ze źródeł, instalacja, debugowanie, umiejętność odpowiedzi na pytanie dlaczego noop na hdd to zły pomysł. Języki: C, pominięty perl/python (tym razem obowiązkowo), ruby Narzędzia: ptrace, strace, gdb, valgrind, syslog Środowiska: systemd, java, mono (C#) CI: Jenkins, TeamCity To jest stos haseł, które powinieneś znać, i potrafić się nimi posługiwać. Umyślnie nie rozwijam żadnego z nich - to ty musisz wiedzieć jak ten stos haseł ze sobą współpracuje i dlaczego dany program został tutaj zawarty. Jestem pewien że pominąłem co najmniej kilkanaście rzeczy które powinny się tu znaleźć, edytuję posta jak sobie przypomnę. Znajomość większości haseł powyżej bez problemu otworzy drogę do wielu firm IT, choć spędzisz co najmniej kilka długich lat jeśli zamierzasz poznać wszystko to co podałem wyżej w stopniu zadowalającym.

W tej cenie najlepsze będą Xiaomi. Zarówno szajsung jak i blackberry się strasznie stoczyły i ich średnia półka jest po prostu słaba.

A tak serio to również ten artykuł mnie wprawił w zdumienie jak łatwo wam przychodzi zrzucanie winy na decyzje poprzednich osób, całkowicie zapominając o tym, że była to wspólna decyzja na kilka lat wcześniej gdy dopiero raczkowaliście jako hosting, a kasa zamiast w maszyny to szła w social media. Awarie zdarzają się każdemu, ale to jak ją ogarnęliście zostawia wiele do życzenia, i przynajmniej ja mam spory niesmak po tym wywiadzie.

U mnie ładnie w Warszawie. IMHO nie warto od razu zakładać najgorszych scenariuszy, akurat UPC przynajmniej u mnie nigdy nie sprawiało większych problemów - warto zadzwonić i się spytać, może po prostu mają jakąś awarię.

Jeśli pytasz czy na KVM/XEM zrobisz to czego teraz zrobić nie możesz - tak.